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Szép új világ? 
Szokásainknak köszönhető- 
en szeptemberben mindig új 
élet kezdődik. Már augusz- 
tusban elkezdődik, mozgo- 
lódik és miután mindenki 
kibámészkodta magát a du- 
nai csillagok háborújában, 
megszületik. Talán logiku- 
sabb volna az újévet au- 
gusztus huszadika környé- 
kére tenni. Bár... Végülis 
megszoktuk már ezt 

a Gregorián-számolgatósdit. 
Szóval, új évad. Ezalatt 

a nyár alatt, míg az emberek többségé- 
nek a hőségtől még fagylaltot nyalni 
sem volt kedve, nagyon sok dolog 
megváltozott. Szervezetek átalakultak, 
új terveket szövögetnek, új emberek és 
csoportok léptek be a linuxos univer- 
zumba, sőt, egyre-másra hallani a híre- 
ket, hogy ez vagy az, így vagy úgy sze- 
retné meglovagolni a hullámokat. Ma 
már a politika és a jogi élet is visszhan- 
gos a szabad szoftverektől, a nyílt for- 
rástól, és — nos, igen — a visszaélésektől. 


Jó ez nekünk, vagy rossz? 
Bánkódjunk-e amiatt, hogy a nyugodt 
kis világunkat felforgatja a politika, át- 
itatják a felhasználási szerződések mi- 
att kitört botrányok? Ma már közhely, 
hogy ez várható volt. Amit sajnálok, 
hogy a közösség nem tudott elég gyor- 
san felkészülni ezekre a gondokra. És 
hogy rajtunk csattan az ostor, amikor 

a kihasználható és lefizethető politiku- 
sok bamba lustaságukban és személyes 
érdekeiket is jócskán szem előtt tartva 
hagyják magukat ,meggyőzni" arról, 
hogy a pénzfaló óriásokat etetni kell, 
hogy a szabad szoftvert nem szabad 
támogatni. Hiszen, ha nem milliárdok- 
ba kerül, akkor még rendes kenőpén- 
zekre sem számíthat az ember! 
Ugyanakkor ne legyünk igazságtala- 
nok. Itt most nem arra gondolok, amit 


félig viccesen szoktunk mondani, hogy 
,nekik is élniük kell valamiből". Abban 
bízok, hogy a szabad szoftver — nyílt 
forrás — akárhogy is hívjuk a társada- 
lom elég erős már ahhoz, hogy meg- 
védje magát. A berozsdált, pénzéhes, 
hatalommal viszont művészien takti- 
kázó óriások nyilván ki akarják lukasz- 
tani ezt a lufit. Bízom benne, hogy 
kénytelenek lesznek rájönni: nem lufit, 
hanem egy sziklatömböt szurkálnak. 


Változások saját házunk táján 
Igyekszünk mi is változni. Örömmel 
hívom fel olvasóink figyelmét például 
dr. Dudás Ágnes sorozatnyitó cikkére 
(Szoftverjog - barát vagy ellenség? 

80. oldal), amelyben nem kisebb fel- 
adatra vállalkozik, minthogy bemutat- 
ja nekünk a szoftverjogot — egyszerű 
halandók által is érthető nyelvezet- 
ben. Remélem, sikerül tisztáznia sok 
kérdést és félreértést ezen a koránt- 
sem letisztult területen. 
Szerkesztőségünkben személyi válto- 
zások is történtek, remélem, ezután fő 
bűneink eltűnnek a szem elől és min- 
denkinek tetszik majd a végeredmény. 
Remélem, hogy már ebben a lapszám- 
ban sikerült olyan kínálatot összehoz- 
zunk, mely mindenkit érdekel. 
Számomra az egyik legkedvesebb 
téma e hónapban örömtelien nagy 
hangsúlyt kap: ez pedig a Windows és 
a Linux közötti átjárhatóság — progra- 
mozás szempontjából. Rendkívül örü- 
lök például a Monóról szóló cikknek 
(Mono: gépfüggetlen hálózati alkal- 
mazások, 16. oldal), remélem, hogy e 
gyönyörű félszerzet továbbra is meg- 
tartja gyors fejlődési képességét. 


Mindenkinek kellemes olvasást kívá- 
nok. És ne feledjék! Érdemes körbenézni 
a nagyvilágban is, szép számmal jön- 
nek a konferenciák, rendezvények, ame- 
lyeken kedvenc pingvinünk ügyes-bajos 
dolgait vitathatjuk meg! 
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Programvadászat 


Előző számunk CD-mellékletén a 
Slackware 10.0-s operációs rendszer 
kapott helyet. A visszajelzésekből kö- 
vetkeztetve, arra jutottunk, hogy a má- 
sodik korong anyagai közül is közre- 
adunk jó pár előlre elkészített csoma- 
got. Ezzel is elősegítve eme kiváló 
rendszer terjedését. 


SystemRescueCD 

Ez a szintén Gentoo alapokkal ren- 
delkező CD-ről indítható linuxváltozat, 
egy kitűnő segédeszköz azoknak a ke- 
zében, akik tudják, hogy a linuxszal 
hogyan lehet linuxot vagy más rend- 
szereket menteni. Nagyon sok segéd- 
eszközt tartalmaz a rendszer, így 
semmilyen feladat végrehajtása nem 
okozhat gondot, használata nagyon 
egyszerű, csak elindítjuk a CD-ről és 
máris nekikezdhetünk a munkának. 





A főbb rendszerelemek: 

" "GNU Parted - Lemezfelosztó 
eszköz 

e.  OtParted - Partition Magichoz 
hasonló lemezfelosztó felület 

s . Fájlrendszer-eszközök: e2fsprogs, 
reiserfsprogs, xfísprogs, jfsutils, 
ntísprogs, dosfstool 

,  Sfdisk — felosztás tábla 
mentő/visszaállító program 

Nagyon fontos lehetőség a vak fel- 

használók támogatása, a Linux 

Speakup 1.5-ös képernyőolvasó reme- 

kül teszi a dolgát. 
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Ezt a CD-t leginkább rendszermentési 
feladatokra használhatjuk, arra 
viszont tökéletes. A fentebbi lista 
korántsem teljes, de az ott felsorolt 
programok jó esélyt adnak arra, hogy 
az ember a féltve örzött, egy esetleges 
rendszerösszeomlás, vagy gondatlan- 
ság miatt elveszni látszó adatait meg- 
menthesse. A rendszerről egy részle- 
tesebb leírás található Fábián Zoltán 
tollából a weboldalunkon. 
(2 http:/www.linuxvilag.hu/ 

system rescue) 


BitDefender 

A BitDefender család, szinte minden- 
féle vírussal kapcsolatos gondra nyújt 
megoldást, a mellékleten a BitDefen- 
der for Linux Mailserver, BitDefender 
for Samba Servers és a webes (web- 
min) karbantaró felület található meg. 


BitDefender for Linux Mailserver 

A leveleket közvetlenül a levelező 

kiszolgálón ellenőrzi és a fertőzött 

üzeneteket hatástalanítja. Függetlenül 

a fogadott vagy küldött üzenet formá- 

tumától, a mellékletek számától és 

beágyazott mélységétől, BitDefender 
védelmet nyújt a fertőzött küldemé- 
nyekkel szemben. Részletes jelentést 
küld a rendszergazdának ezzel is se- 
gítve a rendszer karbantartását. Támo- 
gatott levelező kiszolgálók: Sendmail, 

Omail, Postfix. Szolgáltatások: 

. — vírusellenőrzés, az üzenetet és mel- 
lékleteit is ellenőrzi anélkül hogy lé- 
nyeges terhelést róna a kiszolgálóra 

," gyors működés, több címzettnek 
küldött levelek csak egyszer 
kerülnek ellenőrzésre, nem 
pedig minden egyes üzenet 
továbbításkor 

, . beépített SPAM szűrő 

" telepítés internetről, a telepítés 
konzolon kiadott paranccsal 
indítható: 








wget -g -O - 
http://Tinux.bitdefender . com/ 
webinstall.sh I] sh 

." egyszerű telepítés és üzemeltetés 

, az anti-vírus védelem egyszerűen 
beállítható bármilyen Linux- 
változaton 

" figyelmeztető üzenet küldése 

, . vírusos küldemény észlelésekor 
jelentést küld a rendszergazda 
számára 

, részletes jelentés és statisztika 

. automatikusan készülő jelentés az 
ellenőrzött, fertőzött, hatástala- 
nított, törölt és kiszűrt üzenetekről 

, automatikus frissítés 

, . az okos anti-vírus adatbázis 
frissítés folyamatosan biztosítja az 
email védelem megbízhatóságát 

" " moduláris felépítés 

" távoli felügyelet támogatása 


BitDefender for Samba Servers 
A BitDefender anti-virus felületfüg- 
getlen motorja valós idejű védelmet 
nyújt a Windows, Dos, Linux és Unix 
vírusok és trójai programok ellen. 
Az alkalmazott belső gyorsótár-techno- 
lógiának köszönhetően a valós idejű 
állományok ellenőrzési sebessége na- 
gyon jó. Támogatott Samba kiszolgálók: 
v2.2.x és 3.0. Rendszerkövetelmény: 
. . Minimum P II 300 Mhz, 64 MB 
e Linux rendszer: 

kernel 2.4.x glibc 2.2.3 
. Samba kiadás: v2.2.x vagy 3.0 


Rendszermag 
A legfrisebb rendszermagforrások is 
helyet kaptak a korongon. 


Csontos Gyula 

(Csontos. Gyulaolinuxvilag.hu) 
A Linuxvilág szakmai és 
CD-szerkesztője. Szabadide- 
jében szívesen mászik 
hegyet és kerékpározik. 














Támogatás? Van. 

Az EnfoBridge a jövőben magas szin- 
vonalú támogatást biztosít az 
OpenOffice.org 1.1-es változatához is 
(sajnos csak angol nyelven). Ezzel 

a támogatás hiánya miatti, elsősorban 
a vállalati ügyfelek részéről esetleg fel- 
merülő kifogások alaptalanná váltak. 
A támogatás 30 napig akár ingyenesen 
is elérhető, a 90 napos segítséget pe- 
dig mindössze 14 dollár fejében vehet- 
jük igénybe. Mindez a Flexiety Soft- 
ware Company szolgáltatása, a cég 
már egyéb formákban, például frissí- 
tésekkel is segíti a szabad irodai cso- 
mag használóit. 

5 www.flexiety.com 

3 www.downloadopenoffice.org 


A780 — mi maradt ki belőle? 


A Motorola A780 jelöléssel immár har- 
madik Linuxra és Javára épülő mobilte- 
lefonját jelentette be. Az egyszerűnek 
éppen nem mondható szétnyitható 
készülék a zsebtitkárokéhoz 
hasonló, egynegyed VGA 
felbontású, színes érintőkép- 
ernyőt kap majd, 240 kbit/s 
sebességű, GPRS/EDGE ala- 
pú adatátvitelre lesz alkal- 
mas, rendelkezik majd 
Bluetooth-csatolóval, képes 
lesz a PDF és a Microsoft 
Office formátumú dokumen- 
tumok megnyitására, 

1,3 megapixeles kamerája lesz, le tudja 
majd játszani az MP3 formátumú ze- 
néket, cserélhető-bővíthető memóriá- 
val fog rendelkezni. . . További érdekes- 
sége, hogy négysávos telefon lesz, va- 
gyis az amerikai 800/850 és 1900, illetve 
az európai 900/1800 MHz-es hálózato- 
kat is támogatja. 





Vizsgázni öröm 

A PHP programozással foglalkozó 
phplarchitect magazin bejelentette 
Zend tanúsítványközpontjának 
elindítását. A központ minden 
olyan szolgáltatást — online 
képzést, útmutatókat, gyakorló 
teszteket és vizsgalehetőséget — bizto- 
sít, anely a PHP programozói tudásuk- 
ról valamilyen papírra vágyók számára 
szükséges. Az indulás után a központ 
akciókkal próbálja megnyerni a leendő 
ügyfelek rokonszenvét, illetve a min- 
dent egy csomagban megvásárlók szá- 
mára egyéb kedvezményeket is kínál. 
2 www.phparch.com 
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Bukik a 5C0 

A SCO gyakorlatilag elveszítette azt 
a pert, amelyet a DaimlerChrysler el- 
len indított az autóipari cég Linux- 
használata okán. A SCO célja a GPL 
szerződések érvénytelenségének és 

a Linux-használat jogszerűségének 
megkérdőjelezése volt, ám a bíróság 
gyakorlatilag semmiben nem adott 
igazat a SCO-nak. A SCO egy másik 
autós céget is beperelt, ám azt az 
ügyet elnapolták -— igaz, megfigyelők 
szerint a SCO nem sokat veszít a kés- 
lekedéssel, legfeljebb annyit, hogy 
nem mondják ki a számára kedvezőt- 
len ítéletet. A SCO az IBM-mel is per- 
ben áll, de érvei meglehetősen inga- 
tagok, így az ügy megnyerésére alig 
van esélye. A pereskedés legfeljebb ar- 
ra volt jó, hogy néhány érdeklődőt 
megingasson vagy hátráltasson 

a Linux használatba vételében - ez 
viszont senkinek nem hoz hasznot. 
Bruce Perens szakértő ettől függetle- 
nül óva int mindenkit attól, hogy 

a GPL-t jogszerűnek tartsa, erről 
ugyanis csak egy szerzői jogi per 
során lehetne ítéletet hozni; a mosta- 
niak viszont nem ilyenek. 


Itanium t-Xeon— ? 

2007-re várhatóan egyesül az Intel 
jelenlegi Itanium és Xeon processzor- 
termékvonala. Az AMD Opteron 
processzorainak megjelenése miatt az 
Intel arra kényszerül, hogy megfelelő 
teljesítményű, 64 bites versenytárssal 
lépjen piacra, a megoldás a jelek sze- 
rint az eddig elit kategóriásként sze- 
replő Itanium alsóbb piaci szegmen- 
sekre való bevezetése. 

Az egyesítéshez először is olyan 
alaplapokat, foglalatot és sínrendszert 
kell tervezni, amelyek mindkét pro- 
cesszortípust képes támogatni, ezek 

a munkák már megkezdődtek. A vál- 
tás nemcsak a rendszerépítők számára 
jelent majd könnyebbséget, akik egy- 
szerűbben építhetnek majd különféle 
teljesítményű kiszolgálókat, de a fel- 
használóknak is, akik könnyedén 
bővíthetik majd meglévő rendszerük 
erőforrásait. 


Medgyesi Zoltán 
(mz€rettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Mi újság a rendszermag fejlesztése körül? 


Roland Dreier és az OpenlB.org csapat elkészítet- 
te az InfiniBand verem durva vázlatát, melybe be- 
lepakolták a Mellanox HCA alkatrészek alacsony 
szintű meghajtóit, néhány felső szintű protokollt 
(IP-over-InfiniBand, SCSI RDMA protokoll, sockets 
direct protokoll (SDP), UDAPL és az MPI), ezen kí- 
vül még néhány felhasználói eszközt. 

A kód maga nyílt forrású, de a Micro- 

soft fenntartja szellemi tulajdoni 
jogát az SDP-re és automatiku- 
san nem engedélyezi annak 
használatát a nyílt forráskó- 

dú projektekben. 

Ezért aztán Roland és 

társai kettéosztották az 
InfiniBand csoportot egy 
szabad és egy terhelt 
csomagra, a döntés egy- 

előre úgy tűnik mindenkit 
kielégít. 

Az Intel SourceForge projek- 
tet indított a PRO/Wireless 2100 
miniPCI hálózati adapterének 2.4 

és 2.6-os sorozatú rendszermag 

meghajtójához. 

Bár a firmware csak bináris formában érhető el, 

a projekt egyéb szempontból úgy tűnik nyílt forrá- 
sú módszerekkel dolgozik. A fejlesztőket nyílt leve- 
lezőlistán tartják a kapcsolatot, a frissítéseket 
gyakran közzéteszik, így mindenki ki tudja őket 
próbálni és elmondhatja az észlelt hibákat és 
észrevételeit. 

Egyelőre a kódot korai béta változat kategóriába 
sorolták, így különféle hibák és hiányzó képessé- 
gek várhatók. Ugyanakkor az Intel fejlesztői na- 
gyon oda kívánnak figyelni a különféle Linux ter- 
jesztésekkel kapcsolatos problémákra így remél- 
hetőleg a legtöbb terjesztés alapértelmezett 
telepítéskor csakis ismert, dokumentált módon 
fog megjelenni. 

Niraj Kumar áthozta Linux alá az UFS1 és UFS2-t. 
Az UFS1 már régóta használatos BSD fájlrendszer, 
az UFS2 pedig ennek friss kiterjesztése, melyben 
olyan bővítéseket találunk, mint a 64-bites blokk- 
mutatók és továbbfejlesztett fájltárolás. Niraj 
Linuxos változata jelenleg csak olvasható, hiszen 

a munka még csak most kezdődött. 

Az UFS2 maga is egészen új és még a BSD operá- 
ciós rendszeren sem támogatja például a GRUB 
rendszerindítót. Csak a FreeBSD rendszereken 
alapértelmezett; a Net8BSD továbbra is a hagyomá- 
nyos FEFS fájlrendszert készíti alapértelmezés sze- 
rint. Az UFS2, amelyet eredetileg az UFS1 rend- 
szerből vezetett le Kirk McKusick és Poul-Henning 
Kamp aktív fejlesztés alatt áll. Linux támogatás 








várhatóan gyorsan követi majd a BSD megvaló- 
sítást. 
Michael Geng GPL engedélyű eszközmeghajtót 
készített az I2C-alapú SAA5246A 
Videotext/Teletext dekóderhez, amely a SAA5249 
lapkameghajtóéval megegyező felületet használ. 
Bizonyos részeken Martin Buck munkájára 
alapozó Michael kitisztította a meglé- 
vő kódot és befejezte a munkát, 
így végül a rendszermag hiva- 
talos részeként Andrew 
Morton elfogadta a 2.6-os 
fába. Mint Michael rámu- 
tatott, az újabb TV kártyák 
már nem tartalmazzák 
ezeket a leletex dekóde- 
reket, inkább a CPU-ra 
bízzák a funkciókat. 
De ha mégis megtalál- 
hatóak, ezek a lapkák úgy 
tűnik jobb munkát végeznek, 
így ha lehet érdemes támo- 
gatni őket. 

Az Emulex úgy döntött, nyílt forrásúvá 
teszi a LightPulse Fibre Channel Adapter családjá- 
nak meghajtóját és ennek érdekében SourceForge 
projektet hozott létre. Remélik a kód kitisztul és 
befejeződik végül pedig elfogadják a 2.6-os rend- 
szermag fába. Általában amikor egy cég úgy 
dönt, hogy felszabadítja valamelyik meghajtójá- 
nak forrását, egy sereg baráti üdvözletet kap 
a rendszermagfejlesztőktől, továbbá megjegyzé- 
seket, kritikát a foltokat a kódot elsőként átnéző 
fejlesztőktől. Ez esetben Jeff Garzik végezte 
a legtöbb vizsgálódást, visszajelzések tonnáival 
árasztva el az Emulex fejlesztőit. Jelenleg van 
egy két elég csúnya rész a kódban, amire az 
Emulexes fiúk figyelmeztettek is bejelentésükben, 
de az Emulex úgy tűnik hűen követi a tisztítási 
kívánságokat amelyek szükségesek ahhoz, hogy 
Andrew és a rendszermagfejlesztők elfogadják 
a meghajtót. 

Kristian Soerensen mostanában az Umbrellán dol- 
gozik. Ez az új, kézigépekhez tervezett biztonsági 
eszköz segít a vírusok és egyéb feltörési próbálko- 
zások elleni harcban. Az Umbrella egyik fő előnye 
a félreérthetetlen beállítási rendszer. Minden 
összetettséget száműztek, így a felhasználó 

nem fog szándéka ellenére nemkívánatos réseket 
létrehozni. 


Zack Brown 


Linux Journal 2004. július, 123. szám 
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A Linux Journal 
honlapján számtalan 
gond megoldásához 

találhattok további 
segítséget. A Sunsite 
tüköroldalait, a gyakori 
kérdéseket és az egyéb 

útmutatásokat a 

Dwww.linuxjournal.com 
honlapon olvashatjátok 
el. A rovatban közzétett 

válaszokat Linux-szak- 
értők kis csapata készí- 
tette el. További kérdé- 
seiteket szívesen fogad- 
ják (angol nyelven) a 
Dwww.linuxjournal.com/ 
[/-issues/techsup.htmi 
címen, ahol csak egy 
kérdőívet kell kitöltene- 
tek, de a bis(ossc.com 
címre levelet is írhattok. 
A levél tárgyában 
szerepeljen a ,BIS" 
kulcsszó. 
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A hónap szakmai tanácsai 


AOL Linux alatt? 

Kettős rendszerindításra képes gépem van (GRUB- 
ot használok), az egyik lemezrészre Red Hat Linux 
9.0, a másikra Windows XP Professional rendszert 
telepítettem. Az internetszolgáltatóm által adott 
AOL 9.0 szélessávú alkalmazást is használom. Léte- 
zik illesztőprogram az AOL Broadband Blaster mo- 
demhez, amellyel a Red Hat 9.0 rendszerem is ké- 
pes lenne az AOL szélessávú kapcsolatán keresztül 
az internet elérésére? Nem szeretnék másik szolgál- 
tatóhoz átmenni, új DSL modemet sem szeretnék 
vásárolni, de képtelen vagyok rávenni a Red Hatot 
a Broadxent modem felismerésére. És a Linux az 
AOL szélessávú programcsomagját sem ismeri fel. 
Natosha, NZimardo(o2aol.com 


Az AOL programcsomagja Linux alatt nem használ- 
ható, ezért a hagyományos módszerrel nem tudod 
elérni az AOL szolgáltatásait. Ha viszont általános 
célú internetelérést szeretnél, akkor ajánlom figyel- 
medbe, hogy számos Broadxent DSL modem USB 
és Ethernet csatolófelülettel egyaránt rendelkezik. 
Ha módodban áll áttérni az Ethernet felület haszná- 
latára, illetve be tudsz szerelni egy ethernetkártyát 

a gépedbe, akkor mindkét operációs rendszer alól el 
fogod tudni érni az internetet. Ha DSL modemed 
nem rendelkezik ethernetcsatolóval, akkor vagy 
olyan USB-s eszközre kell lecserélned, amelyet 

a Linux is támogat (például az Alcatel és az ECI ter- 
mékei), vagy olyanra, amely Ethernet csatlakozással 
is fel van szerelve. Ha az AOL nem hajlandó segíteni 
neked mindebben, akkor javaslom, hogy nézz másik 
szolgáltató után. A linuxos asztali gépek napjainkban 
egyre népszerűbbek, különösen a Lindows térnyeré- 
sének és az olyan terjesztők erőfeszítéseinek kö- 
szönhetően, akik a kereskedőkkel együttműködve 
könnyen megfizethető gépekhez mellékelik rend- 
szerüket. 

Chad Robinson, crobinsonarfgonline.com 


Linuxos erőmű összeállítása 

A weben és nyomtatásban egyaránt figyelemmel 
követtem Glenn Stone , Az év linuxos erőműve" cí- 
mű cikksorozatát, és úgy döntöttem, megépítem 

a saját példányomat. Anyagi okokból úgy gondol- 
tam, részegységenként vásárlom össze a gépet: 
minden hónapban megveszem egy-egy darabját, 
majd amikor minden megvan, összeállítom a masi- 
nát. Nem kevés kutakodás után két tanulságot von- 
tam le. 1. Moduláris rendszerben kell gondolkodni. 
2. A 64 bit a jövő. Úgy határoztam tehát, hogy egy 
egyprocesszoros AMD Opteron gépet állítok össze, 
operációs rendszere a Mandrake Linux 9.2/64 válto- 
zata lesz. Az ASUS SK8N alaplapját szemeltem ki, 
emellé 2 GB RAM, két darab Maxtor 120 GB SATA 





HDD, 3,5-ös hajlékonylemezes meghajtó, 5,25-ös 
hajlékonylemezes meghajtó (a munkám miatt szük- 
séges) kerülne, lesz hozzá CD-RVWV-meghajtó 
(48x/12x/48x) és, ha minden igaz, egy DVD-lejátszó 
is. Vajon jól működik ez az alaplap Linux alatt? 

Ha nem, akkor tudsz olyan ajánlani, amivel nem 
lesz gond? 

S.W. Bobcat, swvbobcatXhotmail.com 


Ha gondjaid vannak ezzel az alaplappal, akkor szinte 
biztos, hogy az illesztőprogramok okozzák a bajt. Az 
alaplapokkal kapcsolatos hibák túlnyomó része vala- 
milyen módon megkerülhető, például a noacpi rend- 
szerindítási beállítással. Az említett alaplapot 2003- 
ban számos SPEC.org teljesítménypróbánál használ- 
ták, így erősen kétlem, hogy az esetleges hibáira ne 
volna megoldás. 

Szeretném viszont javasolni, hogy a 64 bites rend- 
szer építését jól gondold meg. Ha nem végzel ko- 
moly képleképezési vagy matematikai munkákat, 

a 64 bites gép nem fog számottevő előnyöket nyúj- 
tani. Sőt, azt fogod észlelni, hogy bizonyos alkalma- 
zások lassabban futnak. A teljesítménypróbák ered- 
ményei jelenleg azt mutatják, hogy ha egy progra- 
mot nem kifejezetten 64 bites gépre írtak, akkor 
nem képes a gép tudásának kihasználására. 

64 bites gépet elsősorban különféle számítási fel- 
adatok végrehajtására érdemes alkalmazni, illetve 
olyan területeken, ahol nagyobb egész számokat 
kell indexeléshez használni, például adatbázisok 
kezelésére. A Descent 3 egy cseppet sem lesz 
gyosabb. 

Nem kérdéses, hogy számos területen jól ki lehet 
használni ezeket a képességeket, feltéve persze, 
hogy minden programot újrafordítasz. Nem vitatható 
viszont, hogy az Opteron egy nagyszerű processzor, 
amely a Hyperlransport megoldásnak köszönhetően 
kitűnően fog teljesíteni a te gépedben is. 

Chad Robinson, crobinsonarfgonline.com 


Tartok tőle, a modularitás tekintetében nem értek 
egyet veled. A személyi számítógépek mára bo- 
nyolultakká váltak, így előfordulhat, hogy amikor 
összeáll a gép, a részei nem működnek megfelelő- 
en együtt, vagy pedig titokzatos hibákat tapasz- 
talsz. Persze nem törvényszerű, hogy így történik, 
ám a PC-k sebességnövekedése több ezres nagy- 
ságrendű, így az ,összekutyulom, és csak lesz belő- 
le valami" megközelítéssel elég nagy esélyed van 
arra, hogy rejtélyes időzítési hibákra bukkanj két al- 
katrész között. Amint magad is írod, a 64 bit a jövő. 
Ez így van, de egyáltalán nem biztos, hogy amire te 
fogod használni a gépet, ott tényleg kell az a 64 bit. 
Lehet, hogy esetedben a , várjunk és majd meglát- 
juk" szemlélet jobb eredményre vezetne, s közben 
talán még egy jó 32 bites gépre is szert tehetnél. 
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Arról nem is beszélve, hogy csak az utolsó alkat- 
rész megvásárlása után lesz valóban működő rend- 
szered, feltéve persze, hogy szerencséd van, és va- 
lóban működik az a vaskupac. Ha az alkatrészeket 
egyenként veszed meg, akkor nemcsak többet 
fogsz fizetni értük, de az elsőként kifizetett részegy- 
ség ára a felére fog esni, mire az utolsó darabot is 
hazaviszed. Ha nem vagy megszállott gépbütykölő, 
és nem akarsz amiatt bosszankodni, hogy a külön- 
féle alkatrészeket cserélgetned kell, mert nem mű- 
ködnek együtt, akkor javaslom, hogy előre összeál- 
lított gépet vegyél. 

Marc Merlin, marc btsOgoogle.com 


Szerintem inkább tedd félre az alkatrészek árát, és 
vedd meg őket egyszerre. Így az első alkatrész ga- 
ranciája nem fog lejárni, mire az utolsót is megve- 
szed. Azt se feledd, hogy, amint Marc is írja, a PC- 
alkatrészek ára folyamatosan csökken. Ha saját 
linuxos gépet szeretnél építeni, akkor látogass el 

a linuxos rendszerépítők weboldalaira, és nézd meg, 
hogy ők milyen eszközökkel dolgoznak. Valószínűleg 
azok gond nélkül működnek egymással. 

Don Marti, dmarti(idssc.com 


Új szolgáltatás hozzáadása 

Írtam egy SMS rendszert Javában, amelyet háttér- 
szolgáltatásként szeretnék futtatni Linux alatt. 

A rendszer egy ".jar állományban van. Hogyan való- 
síthatom ezt meg a Red Hat-ben szolgáltatásként? 
Kasun Perera, kasunoteamwork.Ik 


Létre kell hozni egy parancsállományt, amit 

a /etc/rc.d/init.d/ könyvtárba teszel. Nagyon pon- 
tosan meghatározott formátumúnak kell lennie, 
ahogy ezen az oldalon világosan kiderül: 

2 http:/Avww.sensi.org/—alec/unix/redhat/sysvinit.h 
tml. Azt javaslom, nézz meg más parancsfájlokat 
abban a könyvtárban, hogy megértsd a fájl általá- 
nos formátumát, különösen az első, hozzávetőleg 
illosson 

Felipe Barousse Boué, fbarousseDpiensa.com 


Új szolgáltatás indításakor szeretem lemásolni az 
SSH beállítófájlját, mert általában ez a legegysze- 
rűbb. Tedd bele az összes parancsot, ami ahhoz 
kell, hogy parancssorból el tudd indítani a progra- 
mot. Esetleg be kell állítani néhány környezeti vál- 
tozót egy Java program futtatásához. Futtasd a pa- 
rancssorból a beállító fájlt, hogy meggyőződj, ren- 
desen elindítja és leállítja az új szolgáltatást, majd 
a terjesztés eszközeinek segítségével állítsd be 

a futási szinteket, hogy indításkor futni kezdjen. 
Red Hat-ben használd a chkconfig-ot. 

Don Marti, dmartixdssec.com 





A Webmin gyorsítása 

Webmint és Zonemindert használok a 2.2GHz, 1GB 
RAM rendszeremen, és az eredmény elmarad 

a várttól. Van valami mód arra, hogy felgyorsítsam 
a hurok eszközt? 

Howard Watts, howardwattsosbeglobal.net 


Nemrég frissítettem néhány Webmin rendszert az 
e sorok írásakor legfrissebb, 1.140-es Webminre. 
Lényeges javulást tapasztaltam a működésben. 

Az összes modult is frissítettem, mindezt közvetle- 
nül a Webmin alól. 

Felipe Barousse Boué, fbarousse(opiensa.com 


A hurokeszközön (10) az egyetlen késést a TCP ve- 
rem tiltása okozza, de ennek gyorsan kellene mű- 
ködnie. Ha teljesítmény-problémáid vannak, érde- 
mes megnézni a top nevű programot (lásd a top 
súgóoldalát), hogy kiderüljön, vannak-e ellenőrizet- 
len folyamatok. 

Christopher Wingert, cwingertogualcomm.com 


Winmodem: bütyköljem vagy cseréljem? 
Nem tudom működésre bírni a Creative Labs 
Blaster v92 PCI belső modememet. A Linux 
Conexant lapkakészletet ismert fel, és megpróbálta 
telepíteni a meghajtót, de hibaüzenetet kaptam. 
Próbáljam meg inkább a SuSE Pro 9.0-val? 

Manny, manuel61ojoimail.com 


Valószínűleg a legkönnyebb, és legjobban ajánlható 
megoldás egy nagyon olcsó modem beszerzése, ami 
nem Winmodem. Bizonyára könnyebb lesz a telepí- 
tés, kevesebb bonyodalommal, és olyan modemed 
lesz, amely sok-sok Linux nemzedéken át kitart. Emel- 
lett jelezd a gyártóknak, hogy mindannyian szabvá- 
nyos modemeket akarunk, nem szabadalmazottakat. 
Felipe Barousse Boué, fbarousse(opiensa.com 


Szinte sosem kell az egész operációs rendszert fris- 
síteni csak azért, hogy egy eszközt támogassunk. 
Anélkül, hogy ismerném a pontos lapkakészletet, 
amit használsz, csak azt javasolhatom, hogy először 
állapítsd meg, hogy a te modemed , tiszta vas", 
vagy úgynevezett Winmodem. Azt gyanítom, hogy 
az utóbbi, különben nem lennének nehézségeid. 

A Linux terjesztés frissítése helyett derítsd ki, 
melyik meghajtót próbálta betölteni, és keress 

egy frissebb meghajtót a weben. A Winmodemek 
támogatottsága a Linux alatt egyre növekszik 

(a 5 http:/Avww.linmodems.org például jó kiindulási 
hely). Ha szerencséd van, megtalálod a keresett 
meghajtó újabb, működő változatát, és megspórolsz 
egy csomó fáradságot. 

Timothy Hamlin, thamlinozeus.nmt.edu 
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Valamilyen nyakatekert tanulmányt keresel, ami se- 
gít megérteni a Winmodemeket, vagy egyszerűen 
internet-kapcsolatot szeretnél? Legyen cél a szemed 
előtt, mielőtt választanál a fenti két válasz közül, és 
ne feledd, ha frissítesz, lehet, hogy újra telepítened 
kell a modemet. 

Don Marti, dmartiidssc.com 


Első lépések 

Szeretném megtanulni a Red Hat 9-et. Telepíthetem 
a Windows 2003 Serverrel (Beta) egy gépre? A kö- 
vetkező számítógépem van: 700MHz-es Dell PIII, 
6GB-os merevlemezzel és 128MB RAM-mal. Tudom, 
hogy fel kell majd osztanom a merevlemezt. Láttam 
egy programot, amit az Amazon.com-on árultak, kb. 
70 USD-ért. Ez még új nekem és próbálok tanulni, 
szóval bármilyen segítséget megköszönök. 

Bill, whitesock95829Xoyahoo.com 


Igen, lehet ugyanarra a gépre Linuxot és Windowst 
telepíteni, ezt kettős indítású rendszernek hívják. 
Néhány részletre azonban figyelni kell. A Red Hat 9 
fejlesztését abbahagyták, szóval a Linuxszal való já- 
tékra és tanulásra a Red Hat által támogatott Fedora 
Core 1-et választanám inkább. 

A 5 http://fedora.redhat.com címről letöltheted. 
Felipe Barousse Boué, fbarousseopiensa.com 


A Linuxot úgy próbálhatod ki legkönnyebben, hogy 
letöltöd a Knoppixot a Dhttp://knoppix.org-ról. Így 
kísérletezhetsz a Linuxszal és nem kell módosíta- 
nod a merevlemezt. A legtöbb terjesztés ingyene- 
sen letölthető, a Red Hat 9 is. Érdemes inkább egy 
újabb terjesztést keresni, mint például a Fedora 
Core 

Christopher Wingert, cwingertogualcomm.com 


Én magam nem próbáltam indításkezelőt telepíteni 
a Windows 2003 Serverhez, és nem is áll szándé- 
komban, de sok emberről hallottam, akiknek sike- 
rült. Az eljárás hasonlónak tűnik, mint a Windows 
korábbi változatainál. Íme néhány fontos dolog, 
amit tudni kell: 


1) A Knoppix tartalmazza a OtPartedt-et, egy ingye- 
nes felosztásszerkesztőt. A felülete nem olyan 
kifinomult, de a lemez felosztására ugyanolyan 
jó, mint a PowerCuest Partition Magic-je, és 
más fizetős programok. Talán még lelkes is le- 
szel, hogy ingyenes programmal végzed el a fel- 
adatot. A Knoppix mellesleg nagyon jó biztonsá- 
gi lemezt készít. 

2) Legalább egy lemezrész kell a Linuxnak, és még 
128MB lapozórésznek (swap partition). A véle- 
mények eltérnek a felosztással kapcsolatban, van 





aki szereti a /home, /var és egyéb könyvtárakat 
külön lemezrészeken elhelyezni. Mivel te csak 
most kezded, jobb, ha csak egyet használsz. 

3) Szükséged lehet egy FAT32 lemezrészre is, hogy 
megoszthasd a fájlokat az operációs rendsze- 
fekiközötte 

4) Ha a Windows még nincs telepítve, akkor 
először telepítsd azt, utána oszd fel a lemezt. 

A régi Windowsok nem tűrtek meg másik operá- 
ciós rendszert telepítés közben. Megpróbálha- 
tod megoldani a problémákat, de egyszerűbb, 
ha megelőzöd. 

5) Amikor telepítesz, ne felejtsd el telepíteni 
a GRUB indításkezelőt. A telepítés magától ész- 
leli a Windows jelenlétét. Az indításkezelő betöl- 
tődik a gép indításakor, és felajánl egy menüt, 
amiből kiválaszthatjuk, melyik operációs rend- 
szert akarjuk indítani. 


Bruce Byfield, bbyfieldgaxionet.com 


Nem kell átméretezni a meglévő lemezrészeket fel- 
osztásszerkesztővel, ha van még helyed a merev- 
lemezen. Minden Linux terjesztés tartalmaz valami- 
lyen egyszerű lemezfelosztó eszközt. Ha felosztás- 
szerkesztőt használsz, ne feledd, hogy ha valami el- 
romlik, fontos adatok veszhetnek el. Mindenképp 
csinálj biztonsági mentést az aktuális rendszerről, és 
ellenőrizd, hogy a mentés sikeres volt, mielőtt átmé- 
reteznéd bármelyik lemezrészt. Vagy, ahogy Rick 
Moen javasolja, ha megvan a biztonsági másolat, 
vissza is állíthatod új lemezrészekre, ezzel teljesen 
megspórolod az átméretezést. 

Viszont a 6GB-os lemezed túl kicsi, hogy kényelme- 
sen futtass két operációs rendszert. Beszerezhetsz 
egy új, nagyobb meghajtót a Linux számára. 

Még több tanács található az új felhasználók számá- 
ra, (többek között arról, hogy miért rossz ötlet a ket- 
tős indítás), a Linux Journal webhelyén, a , Welcome 
to Linux, 2004" című cikkben. 

(2 http:/Avww.linuxjournal.com/article/7516). 

Don Marti, dmarti(9dssc.comL 


A Linux Journal weboldalairól számos súgó és 
egyéb erőforrás érhető el. A Best of Technical 
Support rovatban közzétett válaszokat egy Linux- 
szakértőkből álló csoport adja. Ne feledd el megad- 
ni, hogy milyen terjesztést használsz, a rendszer- 
mag melyik változatát futtatod, mi a gondod, vala- 
mint írj meg minden olyan adatot, amelyről úgy gon- 
dolod, köze lehet a hibához. 


Linux Journal 2004. április, 120. szám 


Linux Journal 2004. július, 123. szám 
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2004-es Szerkesztői Díj 
(Editors" Choice Awards) 


Izgatottan vártunk néhány linuxos eszközt és programújdonságot de nem igazán 
tudtunk elszakadni a régi favoritoktól sem. 


gyre nehezebb és nehezebb az 
Be újonnan megjelenő Linuxos ter- 

mékekkel, szolgáltatásokkal és 
projektekkel lépést tartani. Szerencsé- 
re a szerkesztőink körét az utóbbi né- 
hány évben kibővítettük és Szerkesz- 
tői díj egészen előkelővé vált. Minden 
további hűhó nélkül lássuk a 2004-es 
év Szerkesztői Díjait. 


Kiszolgáló: 

HP Proliant BL20p 62 

Az Ibrahim Haddad által javasolt HP 
ProLiant BL20p G2 gép két Intel Xeon 
processzorral rendelkezik, alaplapra 
szerelt RAID, két gyorscserélhető SCSI 
meghajtóval, három Gigabit Ethernet 
csatlakozóval vértezték fel, valamint 
egy további Ethernet kapcsolattal is 
bír a karbantartás végett. Ezen felül 
Fibre Channel kapcsolattal is felszerel- 
hető. Mindez már egy 1U fiókkiszol- 
gálóban sem lenne rossz, csakhogy ez 
egy pengegép, így akár nyolc darabot 
is elhelyezhetünk egyetlen 6U szek- 
rényben maximum hat redundáns 
áramforrással, tetszőleges hálózatkap- 
csolóval vagy más kapcsolattartó esz- 
közzel egyetemben. 

Ha eddig csak a csinos laptop merev- 
lemezek miatt nem rajongtunk a pen- 
gékért, vessünk még egy pillantást 

a nehézsúlyú pengekiszolgálók új 
nemezedékére. 


Személyi számítógép és munka- 
állomás: IBM ThinkPad T41 
Minthogy köztudottan minden szer- 
kesztő más és igen mélyen gyökerező 
véleménnyel van saját munkakörnye- 
zetéről, mindannyian meglepődtünk, 
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mikor Doc Searls, Ibrahim Haddad és 
Robert Love egybehangzóan állította: 
az IBM ThinkPad T41 ma a legkívána- 
tosabb Linux laptop. És nem csak egy- 
szerűen a ThinkPad vagy ThinkPad T 
sorozatban egyezett a véleményük — 
mindannyian ugyanazt a modellt ked- 
velik és használják. 

Doc, aki így dícséri a T41-est , Külsőre 
ipari erőt sugároz és dolgozni vele 
mintha versenyautót vezetnél" a nagy 
teljesítményét kedveli benne. , Min- 
den működik Linux alatt", jegyezte 
meg Robert. Hova tűntek a régi szép 
napok, amikor a kernelbütykölőkre 
vártunk, hogy megvegyék a még 
nem támogatott laptopokat és elvé- 
gezzék számunkra a munkát? A T41 
1400 x1050-es kijelzővel rendelkezik 
és az IBM híres három éves garanci- 
ája, valamint gyors és szakértő szer- 
vízszolgáltatása jár hozzá. 

Bármely gép, amelynek sebessége 

a zsírozott egerekhez mérhető leg- 
alább egy elismerő említést megérde- 
mel, Greg Kroah-Hartman pedig ép- 
pen ilyen hasonlattal illette a Apple 
Power Mac G5 kétprocesszoros válto- 
zatát, ami mindössze egyetlen Linux 
telepítésnyire áll a nagyszerű rend- 
szerré válástól. , Gyors, csendes és jó 
ránézni. Teljes 64-bites teljesítmény 
nagyon olcsón, ki ne szeretne ilyes- 
mit?" írta. 


Biztonsági eszköz: 

Clam AntiVirus (AV) 

Rewven Lerner szerint, ,a ClamAV mi- 
att az üzleti vírus-ellenőrző progra- 
mok tényleg futhatnak a pénzük után. 
A ClamAV és a Spamássassin együtte- 


se nagy mértékben lecsökkentette 

a kiszolgálómon áthaladó idegesítő 
(és potenciálisan veszélyes) levelek 
mennyiségét." 

Az idei év nem-Linux felületeken ki- 
igen jól kezelte és a levelezőlistákon 

a Linux rendszergazdák jelentése sze- 
rint az adatbázis frissítési idők elérték 
vagy túl is szárnyalták az üzleti válto- 
zatokét. Ó igen, ma már üzleti támo- 
gatás is elérhető. 


Webböngésző vagy ügyfél: 

Mozilla Firefox 

Kezdem azt hinni, hogy a Mozilla az 
új Emacs — az a gépfüggetlen prog- 
ram, amely egységes és bővíthető" írja 
Rewven. Júliusi számunkban rövid pél- 
dakódot valamint bemutatót találunk 
a Mozilla alapú alkalmazások fejlesz- 
téséről, ha pedig felbukkanó ablaktól 
mentes, szabványtámogató böngé- 
szésre vágyunk, csak vessünk egy pil- 
lantást a legközelebbi Linux asztalra. 


Grafikus program: The GIMP 

A GIMP Projekt végre kiadta várva- 
várt 2.0-ás változatát, visszaszerezve 
szerkesztőink kedvenc grafikus eszkö- 
zének megtisztelő címét. Marcel 
Gagné szerint, , Az EXIF kezelés, 
CMYK támogatás és az egyszerűbb, 
jobb felület megjelenésével a The 
GIMP program továbbra is vetélytárs 
nélkül maradt a Linux asztalomon." 


Kommunikációs eszköz: mutt 

Bár a gyorsüzenet-küldők és grafikus 
levelezők általában a teljes bemutató- 
időt kitöltik a Linuxos rendezvénye- 
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ken, a szöveges alapú mutt levelező 

— melyben lényegében mindent beál- 
líthatunk - továbbra is kultusz-remek- 
mű marad. Greg szerint, ,e nélkül se- 
hogy sem boldogulnék a napi 500 üze- 
netre rúgó levéladagommal." 

Don Marti Ximian Evolution-t használ 
naptárként és kapcsolatai nyilvántar- 
tására, de levelezésében ragaszkodik 
a mutthoz. A muttot és a Mozillát 
együtt használva kényelmesen néz- 
hetjük a csatolmányokat de egy kis 
egészségesen felspécizett beállítás- 

fájl felhasználásával a webkeresést is 
kipróbálhatjuk a ,my .muttrc" segít- 
ségével. 


Felhasználói program: GnuCash 
,Pár hónappal ezelőtt kezdtem el 
használni a GnuCashtt és teljesen le- 
nyűgöztek a képességei , írja Reuwven. 














GnuCash 


lenyűgöző mennyiségű képességgel 
rendelkezik és Guile segítségével 
programozni is lehet. Ha még soha 
nem próbáltuk meg magunk kezelni 
a pénzügyeinket esetleg bizonyta- 
lanok vagyunk a kettős könyvvitelt 
illetően, a beépített útmutató segít 
nekünk az indulásban." Pénzügyi 
eszköz kettős könyvelés nélkül, olyan 
mint egy grafikus program rétegek 
nélkül. 


Programkönyvtár vagy modul: Panyo 
Ez ugyan új kategória, de épp itt az 
ideje hogy elismerjük a könyvtár-kar- 
bantartókat is. A kódkönyvtár időt ta- 
karít meg és segít elkerülni jó pár hi- 
bát, hiszen lehetővé teszi, hogy az em- 
berek kihelyezzék alkalmazásaik egy 
részét. Mindig örömmel látjuk amikor 
a fejlesztők jó könyvtárakat használ- 
nak fel és nem írnak mindent újra 

a kezdetektől. Reuwven kijelentette, 
,Szeretnék köszönetet mondani vala- 
mennyi keményen dolgozó embernek, 
akik a Pango és egyéb nemzetközi tá- 
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mogatást nyújtó könyvtárak és prog- 
ramok fejlesztésében részt vállaltak 
és ezzel a nem-nyugati típusú írásokat 
is elérhetővé tették Linux alatt. Nek- 
tek köszönhetően, emberek milliárd- 
jai, akik nem beszélnek, olvasnak 
vagy írnak angolul, használni tudják 
a nyílt forrású programokat. Az, 
hogy Mozilla hagyományos változa- 
tával Héber leveleket írhatok és 
OpenOffice.org normál változatával 
is megtehetem ugyanezt, folyamato- 
san lenyűgöz." 


Fejlesztőeszköz: Bitkeeper 

Greg szerint, ,Segítségével rendszer- 
magfoltok millióival birkózhatok meg 
sikerrel. Ez az egyetlen lehetőség, 
hogy sikeresen karbantartsak hét kü- 
lönböző rendszermagfát, és még alud- 
ni is maradjon időm." 

Linus Torvalds meglepő kijelentést 
tett a BitKeeper cég sajtóközlemé- 
nyében - ,Több mint kétszer gyorsab- 
bá tette amunkámat" mondta. Mint- 
ha ez idáig olyan lassú lett volna. 
Ilyen ajánlólevéllel a BitKkeeper min- 
den új forráskódkezelő programot 
kereső cég jelöltjei között helyet 

kell kapjon. 


Adatbázis: PostgreSOL 

,Továbbra is szeretem a PostgreSOL 

és előnyben részesítem a MySOL-lel 
szemben képességei, üzembiztonsága, 
méretezhetősége, Unicode támogatása 
és a szabványokat követő megvalósí- 
tása miatt " , írja Rewven. , Azt mondják 
a MYySOL csapat lenyűgöző betörést 
hajtott végre és nagyon várom, hogy 
az elkövetkező években felzárkózza- 
nak a PostgreSOL szintjéhez. Egyelőre 
azonban mindenkinek a PostgreSOL-t 
ajánlom akinek relációs adatbázis-ke- 
zelőre van szüksége." ért egyet 
Marcel. , Nálam még mindig 

a PostgreSOL az első", írja. , felnőtt, 
nagy tudású adatbázis-kezelő, és az 
első amihez nyúlok ha adatbázist 
használó alkalmazást készítek vagy 
használok." 


Játék: Really Simple Syndication 
(RSS) 

Szerkesztőink valamennyien üzletem- 
berek és egyből felhúzzák az orrukat 
ha játékokra kell szavazni. Éppen 
ilyen emberekre van szükségünk ha 
ki szeretnénk használni cégünk asztali 
gépeit. Igaz ugyan, hogy nem egé- 


szen úgy néz ki mint a Ouake vagy 

a Frozen Bubble amikor a főnök arra 
jár, de a Neten játszó Linuxosok köré- 
ben ez az új favorit. Hívhatjuk blog- 
golásnak vagy szociális programnak, 
a játékosok mindenünnen érkeznek. 
Olyan mint Dungeons and Dragons 
figurákat festegetni vagy focikártyá- 
kat gyűjteni, csak éppen valódi em- 
berekkel. 

A ragasztó pedig ami mindezt egy- 
ben tartja egy egyszerű XML-alapú 
szindikátus formátum, amelyet RSS 
néven ismert meg a világ, s melynek 
honlapjai (például a Technorati) és 
programprojektjei (például a Planet) 
teljesen új megközelítéssel kezdték 
el összeszervezni a webtartalmat. 

Ki a Blogkirály és ki a bozo? Ugorj 
be a Technoratira és kukkantsd meg 
a pontokat. 

Rewven rámutatott, hogy a Linkedin, 
Orkut és Ryze stílusú, mindent az 
egyben szociális lapok nem különö- 
sebben hasznosak, de az állítja, hogy 
,mindannyian valami olyasmit fesze- 
getnek ami új és érdekes." A dolog 
akkor kezd izgalmas lenni, amikor 

a szociális információ átszeli a lap 
határait és bárki végigmászhat rajta. 
Indul a játék! 


Szakkönyv (döntetlen): 

Real-World XML és Hackiny the Xbox 
Paul Barry januári számunkban azt ír- 
ja: Andrew ,nyuszi" Huang Hacking 
the Xbox című műve , fene jó olvas- 
mány". A könyv gyakorlatias útmuta- 
tó arról, hogyan használjuk a gépet 
úgy, ahogy nekünk tetszik és nem úgy 
ahogy bizonyos cégek üzleti modelljé- 
ben elgondolták. 

Rewven szerint a Real-World XML 
Steven Holzner-től ,egy újabb nagy, 
vaskos könyv az XML-ről, amelynek 
valójában nemigen van szüksége nagy 
vaskos könyvekre. Azonban tartalmaz 
néhány példát, mintakódot valamint 
megvitat pár alkalmazást, többek közt 
a SOAP-ot." 

Aki a szépen megszerkesztett könyve- 
ket kedveli, nézze meg Huang köny- 
vét; aki inkább a jó kötőanyagra vá- 
gyik, szerezze be Holzner művét. Tá- 
gítsuk ki látókörünket. 


Nem szakkönyv: Free Culture 
(Szabad kultúra) 

Vajon a Beatallica néhány tagja a Beat- 
les tiszteletbeli tagja szeretne lenni, míg 











más tagjai inkább a Metallicát választa- 
nák? Sajnos nem mehetünk el meg- 
hallgatni a , Got to Get You Irapped 
Under Ice" és az ,Everybody"s Got 

a Ticket to Ride Except for Me and My 
Lightning" című számaikat, ugyanis 

a Beatallica a lemezkiadók ügyvédjeitől 
való félelmében elbujdosott. 

Nem mindig volt ez így. Régebben, 
amikor még Walt Disney a Steamboat 
Willy-t, Buster Keaton Steamboat Bill, 
pyright törvények mások voltak és 

a kreativitást támogatták, nem az ügy- 
védek számláját. Lawrence Lessig pro- 
fesszor Free Culture című művében 
számunkra, Linux és Internetes népek 
számára is hasznos dolgokat mesél 

a szerzői jogról, elmagyarázza a jelen- 
kor copyright gyakorlatát azoknak 
akik még nem ismernék az egész szo- 
morú történetet. Lessig a gyakran fi- 
gyelmen kívül hagyott középutat kép- 
viseli a szerzői jog vitájában. 


Műszaki weblap: LWN 


LWN ismét nyert. Ugyanazt tudjuk 
mondani erről a lapról amit tavaly: ki- 
váló Linux-történet gyűjtemény egyéb 
oldalakról, ideértve a Linux Journal 
lapjait, valamint néhány eredeti mű- 
szaki tartalom. Az aktuális sorozat né- 
hány naptár, képnézegető és rajzoló- 
programot mutat be. 


Nem műszaki vagy közösségi lap: 
Groklaw 

Ha eladtad a televíziódat amikor 

a L.A. Törvény felröppent ez a te la- 
pod. Hagyd, hogy magába szippant- 
son a bukott UNIX forgalmazó, a ko- 
rábban Caldera néven ismert SCO 
csoport tárgyalótermi drámája, és 

a cég véget nem érő pereskedése az 
AutoZone, Daimler-Chrysler, IBM és 
Novell cégekkel. Vajon a SCO ki tudja 
majd kerülni a Red Hat perét? Átadta 
a Novell a UNIX szerzői jogait a SCO- 
nak? Vajon Grace Victorral együtt jön 
vissza? Greg szerint a Groklaw , lapja- 
in több IBM igazgatót találni mint bár- 
mely más lapon." 


Mobile Eszköz: Sharp Zaurus 
SL-6000 PDA 


Ibrahim Haddad választása a legfris- 
sebb Zaurus. A korábbi Zaurusoktól 
eltérően, ebben már megtaláljuk az 
USB támogatást, így USB eszközeink- 
kel együtt használhatjuk tárolásra, há- 
lózatkezelésre és adatbevitelre. A kép- 
ernyő finom 480 x 640, négyszerese az 
eredeti Zaurus felbontásának és meg- 
egyezik a múlt évben bemutatott, 
előző, csak japánban forgalmazott 
Zaurus SL-C700 felbontásával. 

















Sharp Zaurus SL-6000 PDA 


Levelezőlista vagy más támogatói 
fórum: linux rendszermag lista 
(linux-kernel list) 

Greg sokáig latolgatta támogassa-e 

a linux rendszermag listát: ,nagyhan- 
gú, gyakran goromba, de mindig in- 
formatív és soha nem unalmas. És ha 
a felhasználó hajlandó rendes lenni, 
igen hasznos is" mondja. Úgyhogy 
légy rendes. Lehetőleg. 


Az év projektje: Ardour 
Az Ardour nevű digitális hangstúdió 
volt a Linux-alapú rögzítőstúdió köz- 


ponti eleme Aaron Trumm májusi 
cikkében. Dave Phillips pedig 

a Linux Journal weblapjára szánt 
cikkében azt írja, ,az Ardour az ér- 
deklődés középpontjába került 
mindannyiunk szemében, akik pro- 
fi szintű hangvágással dolgoznak" 
valamint , az, hogy az Ardour ilyen 
messze eljutott és ilyen gyorsan fejlő- 
dik, ékesen bizonyítja programozói- 
nak tehetségét és hozzáértését." gra- 
tulálunk Paul Davis-nek és az 
Ardour csapat többi tagjának. 


Az év terméke: 

EmperorlLinux Toucan 

Emlékeznek még az IBM ThinkPad 
T41-re, a laptopra amit mindenki 
kedvel? Doc a sajátját az Emperor- 
Linux-on keresztül vásárolta, e ba- 
rátságos emberekkel teli cégnél, 
akik a fővonalbeli laptopokat ne- 
künk tetsző terjesztéssel szerelik fel, 
foltozott és tesztelt rendszermaggal 
látják el, amely megfelelően támogat- 
ja a laptop alkatrészeit. Az Emperor, 
Linuxszal felvértezett T41-esét 
,Ioucan" néven árusítja és a hat 
terjesztés közül bármelyiket fel is te- 
lepíti rájuk, illetve kérhetünk kettős 
indítási lehetőséget Microsoft OS 
rendszerrel. 

Ami a legjobb az egészben, az 
EmperorLinux nagyon gyorsan vá- 
laszol Linux ügyekben miközben 
tarthatjuk az alkatrészekre. 

Most, hogy a T41 megjelent a Linux 
színen, vajon az IBM operációs rend- 
szer nélküli változatot is elad majd 
az EmperorLinuxnak, hogy a Linux 
vásárlóknak ne kelljen kifizetniük az 
öröklött OS díját? Talán ha pár percre 
befejezik a Groklaw olvasását és meg- 
egyeznek, jövőre kicsit szerencséseb- 
bek leszünk. 


Linux Journal 2004. augusztus, 
124. szám 


Linux Journal Csapat 
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Nono: gépfüggetlen hálózati alkalmazások 


Érdekel a .NET? Próbáld ki ezt az érdekes mintaalkalmazást amely a Mono GUI 


és XML-RPC képességeit aknázza ki. 


Mono nem más mint a Microsoft .NET fejlesztői 
A keretrendszerének Ximian által készített, nyílt for- 

rású változata. A .NET több különböző technoló- 
giát foglal össze: fordítókat több különféle nyelvhez (többek 
közt a Microsoft új programnyelvéhez a Cs-hoz) amelyek 
gépfüggetlen bájtkódot készítenek; a Common Language 
Runtime (CLR) nevezetű virtuális gépet, amely értelmezi 
a bájtkódot, valamint hasznos programokkal teli osztály- 
könyvtárakat a fájlkezelési szolgáltatásoktól kezdve a GUI 
készítésig és kezelésig. A Mono megvalósítás tartalmazza 
a Linux, BSD-alapú rendszerekez (ideértve a Mac OS X 
rendszert) és Windows alatt működőképes CLR-t, valamint 
fordítókat a Cs és Basic nyelvekhez. A Mono fejlesztés alatt 
áll, és a .NET osztálykönyvtár sok része még nem készült el, 
különösen igaz ez a Windows.Forms csoport esetében 
amely a Windows GUI-val dolgozó osztályokat tartalmazza. 
Ugyanakkor a Mono fejlesztői kiadtak egy csomagot a GTK 
felhasználói felület eszközkészletéhez, így 10096 .NET kom- 
patibilitás nélkül is tudunk gépfüggetlen grafikus alkalma- 
zásokat fejleszteni. Cikkünkben bemutatjuk, hogyan lehet 
a Cst, Mono és a Linux hármasával olyan hasznos progra- 
mot készíteni mint a MonoBlog, amely bármely rendsze- 
ren képes futni ahol a Mono és a GIK megtalálható. Vala- 
mennyi tájékozottságot feltételezünk a Glade és a Cs terén, 
persze csak teljesen alapszinten. A hálózati források közt 
hasznos útmutatókat találunk. 


Mono beszerzése 

A Mono weblap útmutatójából megtudhatjuk, hogyan tele- 
pítsük Linux, Mac OS X és Windows rendszerek alá (lásd 

a forrásokat). Két további C$ könyvtárra is szükségünk 
lesz, nevezetesen a GTK$ és XmIRpcCS könyvtárakra. 

A MonoBlogot futtató rendszeren fenn kell lenniük az alap 
GIK könyvtáraknak, melyek egyébként a legtöbb Linux 
rendszeren megtalálhatók. Windows és Mac OS X rendsze- 
rek alatt azonban valószínűleg telepítenünk kell, a csoma- 
gokat a GTK weblapján találjuk (lásd a források között). 

A könyvtárak telepítésére vonatkozó útmutatókat a megfe- 
lelő honlapokon találjuk. 


MonoBlog, a weblogszerkesztő 


A MonoBlog egy weblogszerkesztő program, amely új kül- 
deményeket tud elhelyezni és régieket tud szerkeszteni 
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1. ábra A főablak 


a naplóban, továbbá lehetővé teszi a felhasználónak, hogy 
beállításait megváltoztassa. A legtöbb weblog-rendszeren 
megtaláljuk a MetaWeblog API-ként ismert közös funkció- 
készletet. A MonoBlog ennek segítségével kommunikál 

a különféle weblog programokkal, és nem készít külön-kü- 
lön háttérprogramot a Movable Type, LiveJournal vagy 
Radio Userland rendszerekhez. A példa teljes Cs forrás- 
kódját a Linux Journal FTP oldaláról tölthetjük le (lásd 

a forrásokat). 

Az 1. és 2. ábra a MonoBlog kezelőfelületét mutatja be, ame- 
lyet Linux alatt Glade-del készítettünk. Az 1. ábra főablaká- 
ba a weblog címének és tartalmának felviteléhez használha- 
tó szöveges mezőket, valamint a weblog frissítésére, az űr- 
lap törlésére és a kilépésre szolgáló gombokat találjuk. 

A baloldali fehér rész a GTKTreeView vezérlőelem, amely 

a régebbi küldeményeket jeleníti meg, és ahol a felhasználó 
kiválaszthatja, melyiket szeretné frissíteni. A 2. ábrán látható 
ablakban a felhasználó a MonoBlog és a saját weblogja kö- 
zötti párbeszédhez szükséges adatokat adhatja meg. 


GUI készítés libylade-del 

A GTK egyik hasznos szolgáltatása a libglade könyvtár, 
amely lehetővé teszi, hogy a Glade által készített XML állo- 
mányból készítsük el a program GUI felületét, a grafikus 
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2. ábra A beállítások ablak 
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[4 ; 


$5 Update l (New Post ] $g Ouit 
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3. ábra MonoBlog Red Hat 9 környezetben 


elemek (widgets) kinézetét közvetlenül a kódban adva 
meg. A GTK$é változat is tartalmazza ezt a képességet, így 
a GUI elkészítése nagyon egyszerű. A MonoBlog indítása- 
kor a using paranccsal importáljuk a GTK és Glade névtere- 
ket, majd a konstruktorban megadjuk a következőket: 
Application.InitO; 
Glade.XML gxm] - new Glade.XML("monoblog.glade" , 
enull; nuTDa 
gxm1 . Autoconnect(this5) ; 


Application.RunO ; 


Az Application osztály meghívása minden GTK programban 
kötelező. Az Application. InitO a GIK-t állítja alaphely- 
zetbe, majd az Application.RunO átadja vezérlést a GTK 
főciklusnak, amely figyeli az eseményeket és üzenetet küld 
a jelzések (signals) bekövetkezésekor. A szabványos 
Glade.XML konstruktor három paramétert vár: a Glade-fájl 
nevét tartalmazó szöveget, egy olyan szöveget, amely meg- 
mutatja az objektumnak, hogy a Glade fában melyik cso- 
móponton kezdje el építeni a felületet, végül, a harmadik 
szövegben a kérdéses Glade fájlhoz tartozó fordítási tarto- 
mányt adhatjuk meg. 

A MonoBlog-nak az XinlI állományban található valamennyi 
csomópontot el kell tudnia érni, azaz a főablakot és 

a ,preferences" ablakot is. Fordításra nincs szükség, így 
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a második és harmadik paraméter üres érték marad. Az 
Autoconnect() tagfüggvény (method) a paraméterként 
megkapott objektumhoz fűzi a Glade állományban meg- 
adott jelzéskezelőket (signal handlers) és objektumokat, így 
az objektum válaszolni tud az eseményekre és kezelheti 

a grafikus elemeket. Mivel a MonoBlog aprócska program, 
valamennyi jelkezelést a főablakban végeztem el. Egy na- 
gyobb, összetettebb rendszerben, általában jobb megoldás 
a jelkezelést másik osztályba sorolni. 

A grafikus elemek eléréséhez különleges megadási mód 
szükséges. Mindegyiket példányváltozóként (instance 
variable) kell megadnunk: 

[Glade.Widget] GTKWidgetType widgetname; 


ahol a GTKwidgetType helyére az éppen aktuális objektum- 
típust írjuk, és a widgetname pedig a Glade fájlban meg- 
adott megfelelő elemnév. Az Autoconnect() visszatérése 
után az elemeket pontosan ugyanúgy használhatjuk, mint- 
ha maga program hozta volna létre őket. 


Régi bejegyzések lekérése 

A program betöltése során első lépésként lekérdezi 

a weblogot és letölti a friss küldeményeket, ezután pedig 
megjeleníti őket a TreeView elemben. Mindezt a MonoBlog 
osztály getRecentPosts 0 tagfüggvénye kezeli; a fő 
konstruktor hívja meg, feltéve, hogy a beállítások már meg- 
vannak, hiszen a tagfüggvénynek tudnia kell milyen 
webloghoz akar csatlakozni. A MetaWeblog API egyik függ- 
vényhívása, a metaweblog . getRecentPosts, megadott szá- 
mú régi küldeményt ad vissza, illetve, annyit amennyit ta- 
lál, ha többet kértünk le mint amennyi létezik. 

A webloggal folytatott párbeszéd nagyon egyszerű: 
XmlRpcReguest client - new XmilRpcReguestO ; 
client.MethodName - "metaweblog.getRecentPosts"; 
client.Params . Add(BlogID) ; 

client.Params .Add(Serveruser); 

client.Params .Add(ServerPass); 

client. Params . Add(NumberofPostS5) ; 

XxXmlRpcResponse response - client.Send(ServeruURL) ; 


Új xmIRpcReguest objektum létrehozásához csak a kiválasz- 
tott API függvény nevét kell megadnunk, majd feltölte- 
nünk a szükséges paramétereket és elküldeni a weblognak. 
A weblog visszaküldi a válaszát, jelen esetben a küldemé- 
nyek tömbjét, amit a xmIRpcResponse objektum Value me- 
zőjében tárolódik. Ezután a GTKTreeview vezérlőelemet kell 
frissítenünk. 

A GTK 2.0 és újabb rendszer esetében a vezérlő modell- 
nézet-vezérlő (model-view-controller) megközelítést alkal- 
maz. Itt létrehozzuk az új objektummodellt, és átadjuk 

a vezérlőnek: 

System.Typel] ListTypes - new System.Type[31; 
ListTrypes[0] - typeof(string); 

ListTrypes[1] - typeof(string); 

ListTrypes[2] - typeof(string); 

ListStore store - new ListStore(ListTypes) ; 
treeview1.Model -— store; 


Ez az objektummodell egy háromoszlopos táblázatot hoz 
létre. A ListStore objektumnak Type objektumok tömbjét 
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kell átadnunk; a tömb minden egyes eleme megfelel az 
adott oszlop típusának. A weblog-küldemények három ele- 
met tartalmaznak - a címet, a tartalmat és egy egyedi azo- 
nosítót. Minthogy mindhárom elem szöveg, az összes osz- 
lopnak String típust adunk meg. A tagfüggvény további 
része végiglépdel a tömbön és feltölti a modellt: 
Treelter iter - new Treelter 0; 
foreach (Hashtable post in results) ( 

String title - (String) post [/title"]1; 

String postid - (String) post [/postid"]; 

String description - (String) post 

5 [/description"1; 


store.Append (out iter); 
store.SetvValue (iter, 0, new GLib.Value(title)); 
store.Setvalue Citer, 1, new 

5 GLib.Value(postid)); 
store.Setvalue (iter, 2, 
new GLib.Value(description)); 


Mindez önmagában még nem elegendő ahhoz, hogy a cí- 
meket is megjelenítsük a fában. Ezért egy kis kódot szúrunk 
a konstruktorba, a getRecentPosts O meghívása után: 
Treeviewcolumn Titlecol - new Treeviewcolumn ) ; 
cellRenderer TitleRenderer -— new 

5 cellRendererText0 ; 

Titlecol.Addaáttribute (TitleRenderer, "text", 0); 
treeview1l.Appendcolumn (Titlecol); 


Ezzel az új oszlopnézetet hozzáadtuk a fához. Az 
AddAtrributeO) függvény a modell első oszlopához 
(title) kapcsolódik a 0 paraméterrel. A felhasználónak 
csak a bejegyzések címét kell látnia a Treevi ew vezérlő- 
elemben; több oszlopnézetre nincs szükségünk. Az infor- 
mációt azonban a modellben tároljuk, így programunk ha- 
tékonyabban működik. 


Régi küldemények szerkesztése 
Amikor a felhasználó egy bejegyzésre kattint, azt szeret- 
nénk ha a program a régi bejegyzést megjelenítené az ablak 
jobb oldalán található szöveges mezőben. A MetaWeblog 
API-ban találunk egy metaweblog. getPost nevű függvényt, 
amely a küldeményeket kéri le weblogból. Mivel azonban 
mi már korábban letöltöttük őket a getRecentPosts) 
függvénnyel, a program a modellből is lekérheti az adato- 
kat, nem kell ismét a webloggal társalognia. A Glade segít- 
ségével a row activated jelzést összekapcsoltuk 
a Selectoldpost függvénnyel, így amikor az elemre dup- 
lán kattintunk, a következő kód fut le: 
public void SelectoldPost(System.Object obj, 
5 Eventaárgs e) ( 
TreeSelection currentSelection - 
5 treeview1.Selection; 

Treelter iter; 

TreeModel model - treeviewl.Model; 

currentSelection.GetSelected (out model, 

Sout iter); 
String selected - (string) model .dGetvalue 
eeritersD 
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MonoBlog 


8 zulsalisestrongsálicia Keyssístronge 8mdash; 2a hr 

tn 
Bé séöet ef-"http./wvww.Cs.unc edufrpointeríname.mp3" vo 
The Righteous Fury c u Dont Know My Name (Reggae remix) sfazcdisajulz 


Miracles and Marvels 5/P7 


.2psOne of those fun remixes that manages to compl 
etely change how a song feels, transforming it from 
a wintery ballad to a summer smash. Unfortunately , 
Mondays No Fun Hoses the piano part, but ít makes up for that with a 
Activist Judges Are — big airhorn. Oh yes.zipz 
"StopS40230.CATYO — pszulselisestrong Siny-Sinyeístrongs ámdash; za 
href-http: few CS Uunc edufepointeriknow mp3a" s 
You Dont KnowsfazzAissfulazipa 


2peStarts off like the beginning of a 19805 news pro 
"aramme, and then turns into a lush (ha-ha!) Saint Etie 
nne-type piece. Ouite nice. The album Ive taken this 
from The Joy of Sing-Sing, was liberated from the s. 
econd-hand department of CDAlley in Chapel Hill, fo. 
e 
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4. ábra MonoBlog Windows XP környezetben 


String oldritle - (string) 
5 model . Getvalue(Citer, 0); 
String oldEntry - (string) 


5 model .Getvalue(iter,2); 


TextBuffer buffer - textviewl.Buffer; 
entry1.Text - oldritle; 
buffer. SetText(oldEntry) ; 


oldPostID -— selected; 
EditingoldPost — true; 


A függvény lekéri a GTKTreeview vezérlőben aktuálisan ki- 
választott elemet, majd közelítő (iterator) segítségével címzi 
meg a modellt és keresi ki a szükséges értéket. Ezután kitöl- 
ti a szöveges mezőket a kapott információkkal, majd frissít 
két példányváltozót amelyekre akkor lesz szükségünk ha 

a felhasználó a Post gombra kattint. Ha a program új be- 
jegyzés készítése helyett egy régit szerkeszt, másik Meta- 
Weblog API hívást kell kiadnunk, amihez szükségünk lesz 
a küldemény egyedi azonosítójára. Ezért kell beállítanunk 
a OldPostID és EditingoldPost változókat. 


A weblog frissítése 

Az Update gomb clicked jelzését az onupdatecl icked tag- 
függvényhez rendeltük. Ez a függvény sajnos túl hosszú, így 
nem tudjuk teljes egészében bemutatni a cikkben, de műkö- 
dése nem annyira bonyolult. Először is lekéri a szöveget a két 
szöveges mezőből és elkészíti a küldemény hash-tábla megfe- 
lelőjét; erre a MetaWeblog API híváshoz lesz szükségünk. 
Attól függően, hogy az Edi tingoldpPost jelet beállítottuk-e, 

a függvény metaweblog.newPost vagy metaweblog. editPost 
hívással XML-RPC kérelmet küld a weblognak. Amikor 

a weblog sikeres választ ad vissza, jelezve, hogy a frissítés 
megtörtént, a függvény tisztítja a mezőket és lehetővé teszi 

a felhasználónak, hogy új bejegyzést készítsen. A főablak to- 
vábbi gombjai, a New Post és a Ouit rövid programocskát tar- 
talmaznak. Akárcsak a Post gomb esetében itt is a clicked jel- 
zéseket csatoltuk a MonoBloghoz. A New Post a szöveges me- 
zőket törlő és az EditingoldPost jelet hamisra állító függ- 








IXI Mono8log 





Entry Title 

pej] Is That Mos Def? 

Entry Body 

um fvertaken tnisrrom inejoy or sing-sing, wa 

b liberated from the second-hand department 0 
CDAlley in Chapel Hill, forthe measly price of 

$8. Plus, the man on the counter was very nice 

jand friendly; we had a discussion about The Fla / 

ming Lips and Thejesus and Mary Chain. c/p2 


epzeuls elis cstrongo]oe Henryeistrongz: €m 
Monday: No Fun Idash; ca hrefz"http://www.cs.unc.edu/-pointer/ 
Actívist judges Are Kil 


"Stop6.$8230:Carry 


btop.mp3"oStopcfa: elis c/ul2/po 


lepsThis song ended up becoming Madonnass " 
Dorrt Tell Me", but here ít ís in its original versio 
n, a slow and haunting tango. Definitely worth 
a listen, and thanks a o Laura for bringin 
Ig it to my attention. Oh, and ca href-"http:/fwe 

 joehenrylovesyoumadly.comijoe.htméspar 
je"shis website even includes recipess/az6.£82 
30;c/p2 


epp cdiv class-"musicPlaying" currently playi 
ng: Edwin McCain §mdash; VII Bec/diva 


ÍTÉSE VESSE] [16 ) 
[osz [dez[ dos) 








5. ábra MonoBlog Mac OS X környezetben 


vényhez kapcsoltuk, így a felhasználó újrakezdheti a munkát. 
A Ouit, ahogy annak lennie kell, az Application.ExitO 
GIK hívás segítségével kilép a MonoBlogból. 


Beállítások (preferences) 

A .NET osztálykönyvtár osztályokat is tartalmaz, amelyekkel 
XML állományokból olvashatjuk be beállításainkat. Az 1. lis- 
tában a MonoBlog beállításállományára láthatunk példát. 
Ezeket az értékeket az alább bemutatott getconfigO 
függvény olvassa be: 





Szaktekintély 





private bool getconfig ( 
try í 
AppSettingsReader config - new 
5 AppSettingsReader0O ; 


ServeruUuRL - (string) 
5 config. Getvalue("ServeruURL" , 
5 typeof(string)); 


Serveruser - (string) 
5 config.Getvalue("Serveruser" , 
5 typeof(string)); 
ServerPass - (string) 
5 config.Getvalue("ServerPass" , 
5 typeof(string)); 
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BlogID - (string) config.Getvalue("BlogID", 
5 typeof(string)); 


NumberofPosts - (string) 
config. Getvalue("NumberofPosts" , 
5 typeof(string)); 


catch(Exception problem) ( 
return false; 


1: 


return true; 
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Alapértelmezés szerint az AppsettingsReader objektum 
programfáj1-neve. config nevű állományt keres, ami jelen 
esetben monoblog. exe . config lesz. Ezután a GetvalueO 
függvény segítségével kaphatjuk meg a szükséges beállítás- 
értékeket. A MonoBlog ezt a függvényt a konstruktorában 
hívja meg, még mielőtt megpróbálná letölteni a régi külde- 
ményeket a weblogról, így megkapja a szükséges informá- 
ciókat. Ha az állomány nem létezik vagy az adatok betölté- 
se nem sikerül, a függvény hamis értéket ad vissza. 

A konstruktor csak akkor hívja meg a getRecentPostsO 
függvényt ha a visszatérési érték igaz, így biztosan nem 
használunk fel sérült értékeket. 

A beállítások frissítése már kicsit nehezebb feladat. Először 
is a főablak menüsorában található Preferences pontot 

a Glade Menu Editor-ral az OnPrefsActivate függvényhez 
kötöttük. Ez a 2. ábrán látható párbeszédablakot hozza fel 
majd a mezőket kitölti az aktuális értékekkel, ha van ilyen. 
Amikor a felhasználó a párbeszéd OK gombjára kattint, 

a MonoBlog írissíti a változókat, és a friss adatokat visszaír- 
ja a beállításállományba. Sajnos a .NET osztálykönyvtár 
nem rendelkezik beállításfájl frissítő osztállyal. Minthogy 

a jelen beállítás nem túl bonyolult, készítettem egy 
saveconfigO nevű függvényt, amely megnyitja az alapér- 
telmezett beállításfájlt és a frissített információkat writeO 
parancsok sorozatával visszaírja a lemezre. Ezt valami ki- 
finomultabb megoldással kellene helyettesíteni amely fel- 
építi a helyes XML dokumentumot, de ennél az alkalma- 
zásnál egyszerűbb volt körülményeskedés nélkül kiírni 

az értékeket. 


Hibakezelés 
Minthogy a MonoBlog az interneten dolgozik, ahol a prog- 
ramunktól függetlenül mindenféle gondok adódhatnak 
(hálózati hibák, névkiszolgáló problémák és így tovább), va- 
lamilyen alapvető hibakezelési megoldásra is szüksége van. 
A getRecentPosts() és OnupdateclickedO tagfüggvények 
try. . . catch blokkba kerültek. Végrehajtjuk az internetet 
használó kódot, és ha valamilyen problémába ütközünk 
a következő catch blokk fut le: 
catch(Exception problem) ( 

MessageDialog md — 

new MessageDpialog(MonoBlogwindow, 

DialogFlags.DestroywithParent, 

MessageType. Error , 

ButtonsType. Close, 

problem.ToStringO); 


md.RunO ; 
md.DestroyO; 
3 


következményképpen a képernyőn a problémát ismertető 
hibaüzenete jelenik meg, szöveges üzeneteként átadva 

a Mono CLR-től kapott üzentet. Így a felhasználó folytathatja 
a munkát és lehetőség van javítani a problémán. Ugyanak- 
kor jelenleg a Mono CLR PPC ágán a hibakezelés nemigen mű- 
ködik így ha a program Mac OS X rendszeren tut, a hibake- 
zelés nem fog működni és a program a csendben nem csinál 
semmit. Folyik a munka a PPC átiraton, szóval, mire ez cikk 
a nyomdába kerül, ez a probléma lehet, hogy már a múlté. 
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1. lista XML beállításfájl minta 


c?xm]l version-"1.0" encoding-"utf-8" ?: 
cconfigurationz 

cappSettingsz 

cadd key-"ServerURL" 
value-"http://ww. test . com/mt-xmi rpc. cgi "/5 
cadd key-"Serveruser" value-"example"/s 
cadd key-"ServerPass" value-"password"/s 
cadd key-"BlogID" value-"1"/5 

cadd key-"NumberofPosts" value-"10"7/5 
c/appSettingsz 

c/configurationz 


Fordítás és futtatás 

A Cs programok fordítását az mcs fordítóval végezzük. 
A MonobBlogot a következő paranccsal fordítottuk: 

mcs -r gtk-sharp.dl1] -r glade-sharp.d11 

5-r xmilRpccs.dí1! -r glib-sharp.d1] monoblog.cs 


A -r kapcsoló mutatja milyen háttérre van szüksége a prog- 
ramnak; itt egyszerűen csak azt kell megmutatnunk, milyen 
könyvtárakat használ a MonoBlog. Eredményképpen egy 
monoblog. exe nevű lefordított bájtkódot kapunk. A prog- 
ram futtatásához a Mono CLR-nek ezt a fájlt kell paramé- 
terként megadnunk: 

mono monoblog.exe 


Kifejlesztettünk egy programot Linux alatt amit szinte gond 
nélkül tudunk Windows vagy Mac OS X környezetben futtat- 
ni. Egyszerűen másoljuk a monoblog.exe, monoblog.exe.config 
és monoblog. glade állományokat a másik rendszerre és futtas- 
suk le az imént bemutatott módon a Mono CLR program- 
mal. A 3., 4. és 5. ábra a MonoBlogot mutatja működés közben 
Linux, Windows és Mac OS X gépeken. Semmilyen kódot 
nem kell megváltoztatnunk; a program úgy működik 

ahogy van, feltéve, hogy a futásához szükséges könyvtárak 
elérhetők. 


Osszefoglalás 

Remélhetőleg cikkünkben be tudtuk mutatni, hogyan lehet 
a Mono és a Cs segítségével könnyen és gyorsan gépfüg- 
getlen alkalmazásokat készíteni. Fejleszthetünk az egyik 
rendszeren és biztosak lehetünk benne, hogy a program 
bármely rendszeren futni fog, amely ismeri a Mono és GIK 
könyvtárakat. Maga a MonoBlog program megérett a to- 
vábbi kísérletezésre. Néhány lehetséges fejlesztési irány le- 
het a további formázási lehetőségek, részletesebb hibajelen- 
tések kidolgozása, GikHTMLz kötésekkel készíthetnénk 
HTML előnézet ablakot, valamint a MetaWeblog API egyéb 
lehetőségeit is kihasználhatnánk, például a weblog külde- 
ményeinek törlését is felvehetnénk lehetőségek sorába. 


Linux Journal 2004. július, 123. szám 
lan Pointer munkanélküli végzős számítástechnikus 


az Egyesült Királyságban. A ianosnappishproductions.com 
címen érhető el. 











Windows-fejlesztés Linux alatt 


Fordítsuk és teszteljük a projekt Linux és Microsoft Windows változatát újraindítás 
nélkül! A MinGW és a Wine ingyenes eszközökkel a Win32 felületet akár több 


felületen működő API-nak is nevezhetjük. 


legtöbb Linux Journal olvasóhoz hasonlóan én is 
A elvakult rajongója vagyok minden Linux, GNU és 

nyílt forráskódú dolognak. Saját gépeimen 
Linuxot használok, ezeken programozom, játszom és térí- 
tek másokat, amikor csak lehet. A létező programozási 
munkák nagy része viszont olyan alkalmazások írását jelen- 
ti, anelyek a Washington állam-béli Redmondból származó 
operációs rendszeren futnak. A munkám révén kénytelen 
voltam néhány kisebb alkalmazást írni Microsoft Windows 
felületre. Mivel a futás sebessége lényeges volt, C-ben akar- 
tam megírni a programokat, közvetlenül használva a Win32 
alkalmazásprogramozói felületet. Felmerült bennem, hogy 
ha olyan szabványos nyelvet használok, mint a C, akkor fej- 
leszthetek a szép és kényelmes Linux birodalmamban. 
Ez a cikk egy rövid útmutató ahhoz, hogyan lehet win- 
dowsos alkalmazást fejleszteni linuxos környezetben. Rövid 
bevezetőt adok a windowsos programozásból, majd lépés- 
ről lépésre végigmegyünk egy példaprogram fordításán és 
tesztelésén. Szó lesz még a Wine-ról, hogy hogyan lehet 
a segítségével leegyszerűsíteni a Windows forráskód áteme- 
lését a Linuxba. 


Win32 programozás 

Azoknak, akik a UNIX-féle folyamat-elvonatkoztatás 
egészséges táplálékán nőttünk fel, a Windows-modell 
egyenesen eretneknek tűnhet. A Windows-modell egy 
időosztásos, többfeladatos, többszálú, üzenetátadásos ope- 
rációs rendszer. Most csak az NT-re és a leszármazottaira, 
az 2000-re és az XP-re szorítkozom. Az operációs rendszer 
minden folyamatot egy szálnak tekint. Ez a folyamat- 
összefüggést valamivel könnyebbé teszi, mint a hagyomá- 
nyos nehézsúlyú folyamat-modell, amely a UNIX-hoz ha- 
sonló operációs rendszerekben használatos. Ennek a , min- 
den egy szál" modellnek a következtében viszont minden 
egy globális memóriacímtérben van. A megfelelő jogosult- 
ságokkal és a megfelelő cím birtokában az egyik program 
piszkálhatja a másik program bitjeit. A másik következ- 
mény, hogy a mag által létrehozott adatszerkezetek nem 
rögzített memóriacímeken vannak. Ez azt jelenti, hogy 

a felhasználó programnak kell lefoglalni a kapcsolódó me- 
móriát, mielőtt bármilyen globális adatszerkezetet hasz- 
nálna, például grafikus környezetet. Arról sem szabad 
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megfeledkezni, hogy felszabadítsuk ezeket a szerkezete- 
ket, miután végeztünk, különben memóriatöredezettséget 
okozhatnak. Az 1. lista, amely a Linux Journal FTP oldalán 
elérhető, egy alap , Hello World" program. Nagyrészt 
szabványos, csak a switch utasításon belüli rész érdekes 
igazán. Egy alap programhoz képest elég soknak tűnik 

a kód, de épp ez a baj az alacsony szintű API használatá- 
val. Jó összehasonlítás lenne erre a Linuxban, ha az Xt se- 
gítségével akarnánk kódot írni az X-hez. 

A mainO függvény helyett a Windows GUI (grafikus fel- 
használói felület) alatt futó program winMainO-nel kezdő- 
dik. Ehhez a függvényhez hozzátartozik, hogy a program 
végzi el az egész kezdeti értékadást. Ennek a kezdeti érték- 
adásnak része a windowosztály megadása a főablakhoz, és 
egy visszahívandó (callback) függvény hozzárendelése. Ez- 
után hozzuk létre a főablakot és jelenítsük meg az asztalon. 
Ekkor a vezérlés az üzenetkezelő ciklushoz kerül, és 

a visszahívandó függvény feldolgozza a főablakhoz küldött 
üzeneteket. 

A 5 http:/www.winprog.org-on elérhető egy jó és 

gyors bevezető a Windows programok írásába. 

A webhely szerkesztői egy jó fag-t és egy egész jó, az 
összes alapkérdést átfogó segédletet kínálnak. Természe- 
tesen, a Windows programozás bibliája a vastag , Win- 
dows Programming" könyv, Charles Petzold-tól. Ha ebben 
a kötetben nem találjuk, amire szükség van, még mindig 
elég tekintélyes méretű ahhoz, hogy kiverjük vele az in- 
formációt a legközelebbi Windows-guruból. 


Keresztfordítás 

A GCC-ben az az egyik bámulatos dolog, hogy annyi kü- 
lönböző felületre és operációs rendszerre átültették már. 
Ennek nagy előnye, hogy olyan binárisokat fordíthatunk 
egy felületen, amelyek teljesen más felületen futnak. Én 
rendszeresen fordítok Solaris vagy Windows binárisokat 
a linuxos hordozható gépemen. Ez hihetetlen előny, mert 
lehetővé teszi, hogy a fejlesztés egy ismerős, kényelmes 
környezetben történjen. 

A legtisztább módon úgy kezdhetünk hozzá, hogy vissza- 
megyünk a forráshoz (lásd források). Így pontosan olyan 
beállításokkal és olyan felületen fordíthatjuk a kódot, ahogy 
szeretnénk. Szerencsére, ezt a munkát már elvégezték he- 
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lyettünk. A MinGW Project kedves munkatársai fenntarta- 
nak egy GCC-változatot windowsos binárisok fordítására. 
Ez tartalmazza az összes kapcsolódó állományt, például 

a fejállományokat (headers). Itt megtalálhatók a források, 

a bináris archívumokkal együtt. A programokat RPM-alapú 
és deb-alapú terjesztések számára is becsomagolták. Ha 
Debiant használunk, az apt-get segítségével letölthetjük 

a mingw32 vagy a mingw32-runtime csomagot. Ha testing 
vagy unstable (Sarge, SID) változaton dolgozunk, akkor 

a mingw32-binutils-t is le kell tölteni. 

A GCC legtöbb fordítási lehetősége megtalálható itt 

a MinGW-ben, néhány ráadással. Ha egyszerűen csak lefordí- 
tunk egy programot, különleges lehetőségek nélkül, akkor 
futtatható a konzolról, például ha egy kicsi, egyszerű progra- 
mot szeretnénk írni, amelyikhez nem kell GUI. Mivel ez Win- 
dows és GUI programot akarunk, felkészítjük a kódunkat a 
fent leírtak szerint, és a fordítási parancshoz hozzáadjuk a - 
mwindows kapcsolót. Ez létrehozza egy szabvány Windows 
végrehajtható állomány fordításához szükséges makrókat és 
könyvtári hivatkozásokat. Ha úgy döntünk, hogy bonyolul- 
tabb Windows programot írunk, amely más Windows-szol- 
gáltatásokat is használ, akkor pontosan meg kell adni 

a könyvtárakban a szükséges hivatkozásokat. A Windowsban 
meghatározhatjuk a program erőforrásait, például menüket, 
bitképeket, szöveget és más elemeket. Ezeket az erőforrásokat 
egy külön állományban tároljuk és külön le kell fordítani, mi- 
előtt a végrehajtandó állományhoz kapcsoljuk. Ez a feladat 

a mingw-windres programra marad, amely létrehoz egy ob- 
jektumállományt, amit később a végrehajtható állományhoz 
kapcsolhatunk. Az 1. listában látható egyszerű példaprogram 
fordításához a következő parancsot használjuk: 

mingw-gcc -o examplel.exe example.c -mwindows 


Cseréljük ki a mingw-gcc parancsot bármire, ami az adott 
csomaghoz jó, mint Compiler executable. Íme, van egy élet- 
képes Windows programunk. Ilyen egyszerű! 


Hibakeresés a Winenal 

A Wine a másik nagy adomány azoknak a fejlesztőknek, 

akiknek Windows-felületen kell programokat írniuk. A fej- 

lesztők elképesztő mennyiségű munkát fektettek a Wine-ba. 

Ez a nagyszerű program lehetővé teszi, hogy windowsos 

programokat futtassunk Linux alatt. Ennek az az eredménye, 

hogy a frissen fordított programunkat lefuttathatjuk, és meg- 

nézhetjük, hogy valóban működik-e, ahogy beharangoztuk. 

Ehhez adjuk ki a wine example1. exe parancsot, és látnunk 

kell az ablakot megjelenni az asztalon. A Wine indításakor 

megvan a lehetőségünk, hogy az ablakokat a saját ablakkeze- 

lő felügyelje, és ne a saját asztalukon jelenjenek meg. Ez be- 

folyásolja azt, hogy néz ki az ablak futtatáskor. Ha nem vol- 

tunk elég ügyesek ahhoz, hogy hibátlanul gépeljük be 

a programot, akkor hibakeresésre lesz szükség, hogy kiderül- 

jön, mi nem jó. A Wine ebben nagy segítség lehet. 

A -debugmsg [debugchanne1] lehetőség a Wine egy vagy 

több hibakereső csatornájának eredményét adja kimenetként. 

Példa a lehetséges hibakereső csatornákra: 

e  relay: naplóüzenetet ír, akárhányszor egy Win32 
függvény meghívódik. 

e win: nyomon követi a Windows-üzeneteket. 

e all: nyomon követi az összes üzenetet. 
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Az al! lehetőséget ne használjuk, csak ha valóban szükség 
van rá, mert a kimenet mennyisége könnyen kifoghat 
legrészletmániásabb programozón is. A Wine oldalon meg- 
található a lehetséges hibakereső csatornák teljes felsorolása. 


Eredeti változat fordítása Linuxra 

Most van egy csodálatos, működő, hibamentes progra- 
munk, amely Windows alatt fut. Tekintve, hogy az egész 
munkát Linux alatt végeztük, nem lenne nagyszerű, ha 

a program Linux alatt is futna? A Wine Project kedves mun- 
katársai ismét a segítségünkre sietnek. A projekt egyik része 
tartalmazza a winelib könyvtárat, amely a Windows forrás- 
kód számára biztosítja a linuxos illesztőfelületet. Hogy 
használhassuk ezt a szolgáltatást, telepíteni kell a wine- 
devel csomagot a terjesztéshez. Ha forrásból telepítettünk, 

a szükséges fájloknak már hozzáférhetőnek kell lenniük. 

A wine-devel csomag egy winemaker nevű Perl parancsállo- 
mányt tartalmaz, amelynek az a feladata, hogy végigmen- 
jen a forrásfájlokon és könyvtárakon, és végrehajtsa 

a Linux winelib könyvtárában történő helyes fordításhoz 
szükséges változtatásokat. Olyan dolgokat ellenőriz, mint 
az állománynevek nagy- vagy kisbetűs írásmódja és a sor- 
tott perjeleket kicseréli hagyományos perjelekre, és sok 
más dolgot elvégez. Alaphelyzetben biztonsági másolatot 
készít azokról az állományokról, amelyeket meg kell vál- 
toztatnia. Átalakítja a projektet winelibbé, miden változta- 
tást magától elvégezve. A fordításhoz egyszerűen futtassuk 
a következő parancsokat, ami által linuxos végrehajtható 
állományt hozunk létre. 

winemaker . 

. /configure --with-wine-/elérési/út/wine 

make 


A fenti pont szándékosan van ott. Megadjuk az elérési utat, 
amelyben a winemaker megtalálja a vizsgálandó forrásfájlo- 
kat. Itt a fájlok az aktuális könyvtárban vannak. 

A mi esetünkben a példában nincsenek projektfájlok, és ezt 
a winemaker problémaként érzékeli. A szükséges lépéseket 
egyszerűen elvégezhetjük kézzel. A program fordítására 

a mingw-gcc végrehajtása helyett winegcc-t használjuk, 
pontosan ugyanazokkal az értékekkel. Ez létrehoz egy . so 
végződésű állományt, és egy héjprogramot, amely a prog- 
ram futását felügyeli. Most már lefordítottuk a Windows 
forráskódot, és működik Linux alatt. 


Következtetés 

Remélem, sikerült meggyőznöm néhány windowsos fej- 
lesztőt arról, hogy hatékonyan dolgozhatnak Linux alól. 

A GCC-vel, ami lehetővé teszi windowsos végrehajtható ál- 
lományok fordítását és a Wine-nal, amely sok támogatást 
nyújt a futtatáshoz és a hibakereséshez, legtöbbször nincs 
oka, hogy egyáltalán elindítsuk a Windowst. Az egyetlen ok 
az lehet, ha a kedvenc fejlesztőkörnyezetünk nem fut 
rendesen Wine alatt. Szerencsére egyre több rendszer fut 
hibátlanul Wine alatt is. 


Linux Journal 2004. július, 123. szám 
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A DIMA használata 


DMA segítségével az eszközök a processzor terhelése nélkül tudják írni és 
olvasni a memóriát, amivel felgyorsul a be- és kiviteli műveletek végrehajtása. 
Tekintsük át, hogy a rendszermag hogyan követi figyelemmel a processzor háta 


mögött történő eseményeket. 


DMA (direct memory access) a közvetlen memória- 
A hozzáférés rövidítése, és segítségével az eszközök, 

rendszerelemek képessé válnak a központi memó- 
ria tartalmának módosítására. Mindezt úgy, hogy az ada- 
toknak nem kell áthaladniuk a processzoron. A DMA hasz- 
nálatának előnye pontosan a processzor munkájának zavar- 
talanságából fakad. A rendszer kérheti az adatok elhelyezé- 
sét adott memóriaterületen, és a művelet befejezéséig nyu- 
godtan foglalkozhat egyéb teendőivel. A DMA használatá- 
val kapcsolatos bajok nagy része ugyanakkor éppen abból 
ered, hogy a processzort kihagyjuk a játékból. 
Ezek a bajok három csoportra oszthatók. Az első oka, hogy 
a processzor jó eséllyel memóriakezelő egységgel rendelke- 
zik. Az a cím, amelyet a processzor a memória adott terüle- 
tének címzésére használ, nem feltétlenül egyezik meg a te- 
rület fizikai címével. Másodszor, a központi memóriába 
történő írások miatt előfordulhat, hogy a memória és a pro- 
cesszor közötti gyorstárak tartalma elavulttá válik. 
(Lásd: ,A gyorstárazás rejtelmeit" , Linuxvilág, 2004. április) 
Harmadszor: a be- és kiviteli (I/O) sínen is lehet memória- 
kezelő egység (IOMMU). Ebből következően előfordulhat, 
hogy az eszköz által az adatok továbbításakor használt sín- 
cím nem egyezik meg a fizikai memóriacímmel vagy a pro- 
cesszor által használt képzetes memóriacímmel. Az ilyen 
megoldások az x86-os világ lakói számára meglehetősen 
idegennek hatnak. A GART-ok (graphical aperture 
remapping table — grafikus ablakleképező tábla) AGP sínen 
való használatával ugyanakkor az x86-hívők IOMMU vo- 
natkozású ellenállása gyengülni látszik. 
A Linux rendszermag DMA-kezelő API-jának mindhárom 
problémaforrást figyelembe kell vennie, és a gondok tény- 
leges fellépését meg kell előznie. Mindezek mellett, mivel 
az eszközök felől a DMA alapú átvitelek túlnyomó része 
egy külső sínen zajlik, újabb három kérdés merül fel. Az el- 
ső az, hogy a [/O eszköz címszélessége eltérhet a fizikai 
memóriacímek szélességétől. Az ISA-s eszközök például 24 
bites, a 64 bites rendszerekben pedig egyes PCI sínre illesz- 
kedő eszközök csak 32 bites címzésre képesek. A második, 
hogy a [/O sín vezérlője is gyorstárazhatja a kéréseket. 
Ilyesmire elsősorban a PCI-sínen kerülhet sor, itt az írási 
kéréseket a PCI-vezérlő visszatarthatja abban a reményben, 
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1. ábra Címtartományok DMA alatt 


hogy több kérést is összegyűjtve gyorsabb átvitelt valósít- 
hat meg. Ezt a műveletet, jelenséget nevezzük PCI-kötege- 
lésnek. A harmadik kérdéses dolog azzal függ össze, hogy 
az operációs rendszer olyan területre kérhet továbbítást, 
amely saját képzetes memóriaterében összefüggő ugyan, ám 
a fizikai memóriában töredezett; ennek oka általában az, 
hogy az átvitel több lapot is érint. Az ilyen átvitelek lebonyo- 
lításához szétszóró/gyűjtögető (Scatter/Gather — SG) listákra 
van szükség. 

Írásomban kizárólag az eszközök kezelését segítő DMA 
API-val foglalkozom. A 2.6-os Linux új általános eszközmo- 
dellje rendkívül elegáns lehetőséget biztosít az eszközök jel- 
legzetességeinek leírására és — egy hierarchikus fa révén — 
sínjellemzőik megállapítására. Az említett csatolófelületek 

a 2.4 - 2.6 áttérés során fontos ellenőrzéseken és módosítá- 
sokon estek át. Az itt szereplő általános elvek ugyan a 2.4-es 
sorozatra is érvényesek, az API és a rendszermag itt emlí- 
tett képességei csak a 2.6-os sorozattal jelentek meg. 


56 listák 

A DMA alapú átviteleknél figyelembe kell venni, hogy a fel- 
használó nagy mennyiségű, akár több MB-nyi adat továbbí- 
tását kérheti az adott pufferbe. A képzetes memória kezelé- 
si módja miatt előfordulhat, hogy ez a képzetes térben 
összefüggő terület számos, a fizikai memória különféle ré- 
szeire szétszórt lapból áll. A Linux elvárja, hogy minden 
lapnyi méretűnél (x86-os rendszereken ez 4 KB) nagyobb 
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átvitel SG lista segítségével történjen. A listát normál eset- 
ben a blokkos [/O réteg (BIO layer) állítja elő. Az illesztő- 
program egyik alapvető feladata a blokkos [/O réteg azon 
működési beállításainak megadása, amelyek alapján a [/D 
műveletek SG listaelemekre való felosztása történik. 

Szinte minden olyan eszközt, amely nagy mennyiségű adat 
mozgatását végzi, úgy terveznek, hogy az ilyen átviteli ké- 
réseket SG listák formájában tudja fogadni. Ugyan a listák 
pontos formátuma a legtöbb esetben eltér a rendszermag 
által előállítottól, az átalakítás csak kivételes esetben jár ko- 
molyabb nehézséggel. 


1/0 memóriakezelő egységek (IOMMU) 

Az IOMMU olyan memóriakezelő egység, amely a [/O sín 
(vagy több szintre rendeződő sínek) és a központi memória 
között helyezkedik el. Működése teljesen független a pro- 
cesszorba épített memóriakezelő egységétől. Ha egy eszköz 
és a központi memória között átvitelt szeretnénk indítani, 
az IDMMUt fel kell programozni az átvitel során szüksé- 
ges címfordításokkal, nagyjából úgy, ahogy a processzor 
memóriakezelő egységével tennénk ezt. Ha ezt megtesszük, 
akkor a blokkos [/O réteg által létrehozott SG listák úgy ad- 
hatók meg az IDMMU-nak, hogy a sínen lógó eszköz szá- 
mára a memóriaterület újfent összefüggőnek tűnjön. 


GART-ok és az IOMMU kihagyása 

A GART alapvetően egy egyszerű IOMMU. Egy, a fizikai 
memóriában található ablakból és egy laplistából áll. Felada- 
ta az ablakba eső fizikai címek leképezése a listában szerep- 
lő fizikai lapokra. Az ablak általában elég keskeny, például 
128 MB méretű, így a fizikai memóriának az ablakon kívül- 
re eső elérései nem képeződnek le. 

Ez az apró hiányosság azonnal rá is világít a Linux rend- 
szermag jelenlegi DMA-kezelésének egyik hibájára: a DMA 
API-k egyike sem képes hibával visszatérni, ha a memória- 
leképezés sikertelen. A GART-ok csak korlátozott nagyságú 
leképezési címtérrel rendelkeznek, és ha ez kimerül, akkor 
nincs több leképezésre lehetőség, legalábbis amíg néhány 
[/D művelet be nem fejeződik, és kellő nagyságú terület fel 
nem szabadul. 

Egyes esetekben a GART-okhoz hasonlóan az IODMMU-kat 
is fel lehet programozni úgy, hogy a [/O sín és a meghatá- 
rozott ablakokba eső memória között ne végezzenek cím- 
leképezést. 

Ezt kihagyásos módnak nevezzük, és érdemes tudni róla, 
hogy nem minden IOMMUL-típus támogatja. A kihagyásos 
módot akkor érdemes használri, ha a leképezés miatt rom- 
lik a teljesítmény, és az IDMMU-t eltávolítva az adatok útjá- 
ból nagyobb átviteli sebességet lehet elérni. 

A blokkos [/O réteg alapesetben feltételezi, hogy ha találha- 
tó IDMMU a rendszerben, akkor használjuk is azt, és ennek 
megfelelően számítja ki az eszközök SG listája által igényelt 
hely méretét. Jelenleg nincs lehetőség arra, hogy a blokkos 
[/O rétegnek jelezzük, az eszköz ki szeretné hagyni a folya- 
matokból az IOMMU-t. 

Baj akkor van, ha a blokkos [/O réteg IDMMU jelenlétét fel- 
tételezi, valamint azt, hogy az SG bejegyzéseket az IODMMU 
állítja össze. Ilyenkor, ha az illesztőprogram az TLOMMU ki- 
hagyása mellett dönt, akkor több SG bejegyzés keletkezik, 
mint amennyit az eszköz megenged. 
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Már megkezdődtek azok a munkák, amelyek e két hibafor- 
rásnak a 2.6-os rendszermagból való eltüntetését célozzák. 
Az IOMMU kihagyásos hibára készült javítást már vizsgál- 
ják. A megoldás az illesztőprogramok készítői számára lát- 
hatatlan lesz, a kihagyásokról ugyanis az alapkód fog hatá- 
rozni. A leképezési hiányosságok elhárításához valószínű- 
leg a leképező API-k hibajelzési képességeinek megvalósítá- 
sára lesz szükség. Mivel a munka a rendszer minden DMA- 
illesztőprogramjára kihat, elvégzése várhatóan eléggé el 
fog húzódni. 


Sínszélességek és DMA maszkok 

Annak érdekében, hogy a lehető legnagyobb címzési széles- 
séggel végezhesse az adatcseréket, minden általános eszköz 
rendelkezik egy DMA maszk nevű értékkel, amely az elér- 
hető címvonalakat kiválasztó maszkbiteket tartalmazza, és 
amelynek beállítása az illesztőprogram feladata. A DMA 
szélességmaszk kétféle jelentést hordozhat, attól függően, 
hogy használunk-e IOMMU-t. Ha igen, a DMA maszk egy- 
szerűen a leképezhető síncímek tartományát korlátozza, ám 
az IDMMU segítségével az eszköz a fizikai memória min- 
den részét el tudja érni. Ha nincs IOMMU, a DMA maszk 
abszolút korlátot jelent az eszközre nézve. Ekkor az eszköz 
a fizikai memóriának a maszkon kívülre eső részeire nem 
tud adatokat továbbítani. 

A szétszóról/gyűjtögető listák készítésekor a blokkos réteg 

a DMA maszk alapján dönti el, hogy az adott lapot át kell-e 
tükrözni. Tükrözés alatt most azt értjük, hogy a blokkos ré- 
teg vesz egy, a DMA maszkon belülre eső lapot, és minden 
adatot átmásol rá egy a tartományon kívülre eső lapról. 
Amikor a DMA használata befejeződött, a blokkos réteg 
visszamásolja az adatokat a tartományon kívüli lapra, majd 
felszabadítja a tükrözött lapot. Természetesen az oda-vissza 
másolgatás rontja a hatékonyságot, ezért a gyártók általá- 
ban arra törekednek, hogy kiszolgáló kategóriájú gépeiknek 
ne legyenek DMA maszk-vonatkozású korlátaik. 


A DMA és az egységesség viszonya 

A DMA alapú átvitelek a processzor közreműködése nélkül 
folynak, tehát a rendszermagnak biztosítania kell egy olyan 
API-t, amely képes a processzor gyorstárainak tartalmát 
összhangba hozni a DMA alapú átvitel által érintett memó- 
riaterületek tartalmával. Fontos, hogy a DMA API a rend- 
szermag képzetes címeinek figyelembe vételével biztosítsa 
a processzor gyorstárainak frissítését. A gyorstáraknak a fel- 
használói térbeli memóriatartalom változásait követő frissí- 
téseire egy másik API-t kell használni. 


Sínkötegelés 

A felső kategóriás sínvezérlő lapkák néha gyorstárral is ren- 
delkeznek. Az alapötlet az, hogy a processzor felől a lapka- 
készlet felé végzett írások végrehajtása gyors, a sínen ke- 
resztül végrehajtottaké viszont lassú, vagyis ha a sínvezérlő 
gyorstárazza az írásokat, a processzornak nem kell megvár- 
nia befejezésüket. A sínkötegeléssel ahogy az ilyen jellegű 
gyorstárazást nevezzük az a baj, hogy a processzornak 
nincs utasítása a sín gyorstárának kiürítésére. A gyorstár 
ürítése — a helyes sorrend biztosítása érdekében - szigorú 
szabályrendszer szerint történik. Az első szabály az, hogy 
csak memória alapú írásokat szabad gyorstárazni, a [/O té- 








ren keresztül történőket nem. A második szabály szerint 

a memória alapú olvasások és írások sorrendjét szigorúan 
meg kell őrizni, még az írások gyorstárazásakor is. Az utol- 
só szabály lehetővé teszi az illesztőprogram írója számára 

a gyorstár kiürítését. Ha memória alapú olvasást indítunk 
az eszköz memóriaterületének bármely szakaszára, az 
összes gyorstárazott írás elvégzésére garantáltan sor kerül 
az olvasás megkezdése előtt. 

A kötegelés kezelésében semmilyen API segítségére nem 
számíthatunk, az illesztőprogramok íróinak tehát maguk- 
nak kell ügyelniük a kötegelési szabályok betartására, ami- 
kor olvassák vagy írják az eszköz memóriaterületét. Egy öt- 
let: ha végképp nem tudunk semmilyen értelmes és szüksé- 
ges olvasási műveletet kitalálni, amivel elérhetnénk a füg- 
gőben lévő írások végrehajtását, egyszerűen olvassunk ki 
egy szakaszt az eszköz sínbeállításai közül. 


A DMA API használata illesztőprogramban 

Az API-ról kimerítő leírást találhatunk a rendszermag leírá- 
sait tartalmazó könyvtárban (Documentation/DMA-APL.txt). 
Az általános DMA API-nak van egy párja is, amely csak PCI 
eszközökkel működik, ennek leírása 

a Documentation/DMA-mapping.txt fájlban található. A to- 
vábbiakban szeretném nagy vonalakban áttekinteni azokat 
a lépéseket, amelyek a DMA helyes működésének elérésé- 
hez szükségesek. Részletesebb tájékoztatást az imént emlí- 
tett leírásokban lehet találni. 

Az illesztőprogram elindításakor az első lépés a DMA 
beállítása: 


int dma set mask(struct device "dev, u64 mask); 


Itt a dev az általános eszköz, a mask pedig a beállítani kívánt 
maszk. A függvény igaz értékkel tér vissza, ha a maszkot 

a rendszer elfogadta, és hamissal, ha nem. A maszk vissza- 
utasítására akkor kerülhet sor, ha a tényleges rendszerszéles- 
ség kisebb. Egy 32 bites rendszer például elutasítja a 64 bites 
maszkot. Ha tehát tudjuk, hogy az eszköz 64 bites címzésre 
képes, először 64 bites maszkkal kell próbálkoznunk, majd 
ha ennek beállítása sikertelen, akkor 32 bitessel. 

A következő művelet a várakozási sor lefoglalása és kezdeti 
értékek megadása. Ennek ismertetése meghaladja írásom 
kereteit, de a Documentation/block/ alatt pontos leírást lehet 
találni róla. Ha megvan a várakozási sor, két alapvető beállí- 
tást kell megadnunk. Elsőként állítsuk be az SG tábla legna- 
gyobb méretét (vagy engedélyezzük tetszőleges nagyságú 
elfogadását): 


void bIlk gueue max hw segments(reguest gueue t "g, 
S unsigned short 


5 max segments); 


Másodikként - szükség szerint — adjuk meg a legnagyobb 
méretet: 


void blk gueue max sectors(reguest gueue t "g, 
s unsigned short max sectors); 


Az utolsó lépés a DMA maszk beprogramozása 
a várakozási sorba: 
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void blk gueue bounce limit(reguest gueue t "ag, 
5u64 max address); 


Általában a max address a DMA maszkkal egyenlő, ám 
ha IDMMU-t használunk, akkor a max address-t 

BLK BOUNCE, ANY értékre kell állítani, ezzel tilthatjuk meg 
a blokkos réteg számára a tükrözést. 


Az eszköz működése 

Egy eszköz működéséhez szükség van egy reguest függ- 
vényre (lásd a blokkos I/O leírását), az alábbi paranccsal ez 
fogja kivenni a várakozási sorból a kéréseket: 


struct reguest "elv next reguest(reguest gueue t "g); 


A kérésben igényelt leképezési bejegyzések számát a reg- 
nr. phys. segments tartalmazza. Létre kell hoznunk egy ilyen 
méretű ideiglenes táblát, sizeof(struct scatterlist) 
méretű egységekkel, majd ideiglenes leképezést kell meg- 
adnunk: 


int blk rag map. sg(reguest gueue t 7"g, 
sstruct reguest "reg, 
S struct scatterlist "sglist); 


Ezzel megkapjuk a felhasznált SG listabejegyzések számát. 
Az alábbi paranccsal a blokkos réteg által biztosított ide- 
iglenes táblát kapjuk meg, ennek leképezése végül így 
történik meg: 


int dma map sg(struct device "dev, 
sstruct scatterlist "sglist, int count, 
s enum dma data direction dir); 


Itt a count a visszatérési érték, az sglist pedig 

abilk rag map. sg függvénynek átadott listával egyezik meg. 
A visszatérési érték a kérésben igényelt SG listabejegyzések 
tényleges száma. 

Az SG listát újra felhasználjuk és a tényleges bejegyzések- 
kel töltjük fel, amelyeket az eszköz SG bejegyzéseibe kell 
beprogramozni. A dir némi segítséget nyújt a gyorstárak 
tartalmának egységesen tartásához. Háromféle értéket 
vehet fel: 


1. DMA TO DEVICE: Az adatátvitel a memória felől az esz- 
köz felé történik. 

2. DMA FROM DEVICE: Az eszköz a központi memóriába 
továbbít adatokat. 

3. DMA BIDIRECTIONAL: Nem tudunk semmit az adatátvitel 
irányáról. 


Az SG lista végigjárásakor és az eszköz SG listájának feltöl- 
tésekor két makrót kell használni: 


dma addr tsg dma address(struct scatterlist 
s ssglist entry); 


int sg dma len(struct scatterlist "sglist entry); 
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Ezek rendre az egyes bejegyzésekhez tartozó fizikai síncí- 
met és szegmenshosszt adják vissza. A kérés leképezését 
azért két lépésben végezzük, mert a blokkos [/O réteget ál- 
talános kódként tervezték, és így nincs kapcsolatban a gép- 
típustól függő, az IDMMU programozására képes alapré- 
teggel. Az egyetlen dolog tehát, amelyet a blokkos I/O réteg 
ki tud számítani, az az IDMMU által a kérés miatt létreho- 
zott SG szegmensek száma. A blokkos [/O réteg nem ismeri 
az IDMMU által ezekhez a szegmensekhez rendelt síncíme- 
ket, ezért egy az összes leképezendő lap fizikai címét tartal- 
mazó listát kell átadnia. A géptípustól függő réteggel 

a dma map. sg függvény tartja a kapcsolatot, továbbá ez 
végzi az IDMMU programozását és a fizikai síncímek listá- 
jának lekérését is. Ez a két tényező az, ami miatt a blokkos 
[/O réteg listája több elemet tartalmaz, mint a DMA API ál- 
tal visszaadott. 

A DMA alapú átvitel befejezése után a DMA tranzakciót le 
kell zárni: 


int dma unmap sg(struct device "dev, 
S struct scatterlist "sglist, 
sint hwcount, 
s enum dma data direction dir); 


Itt az összes átadott érték a dna map. sg hívásakor alkalma- 
zottal egyezik, kivéve a hwcountot, amely a függvény 
visszatérési értékét tartalmazza. Végső lépésként a koráb- 
ban lefoglalt SG listát fel kell szabadítani, a kérés ezzel telje- 
sítettnek tekinthető. 


DMA területen található adatok elérése 

Az illesztőprogramok általában nem nyúlnak hozzá az álta- 
luk továbbított adatokhoz. Előfordulhat azonban, hogy az 
illesztőprogramnak meg kell vizsgálnia vagy módosítania 
kell az adatokat, mielőtt továbbadná őket a blokkos réteg- 
nek. Ehhez a processzor gyorstárait összhangba kell hozni 
az adatokkal: 


int dma sync sg(struct device "dev, 
Sstruct scatterlist "sglist, 
sint hwcount, 
ssenum dma data direction dir); 


Az átadott értékek a dma unmap. sg hívásnál látottakkal 
egyeznek. 

Az adatok elérésével kapcsolatosan a legfontosabb ténye- 
ző az elérés időzítése. Az elérési szabályok a dir értékétől 
függenek: 


e DMA TO DEVICE: Az adatok módosítása után 
és az eszköznek való elküldése előtt meg kell hívni 
az API-t. 

e DMA FROM DEVICE: Az API-t az után kell meghívni, 
hogy az eszköz átadta az adatokat, de még az előtt, 
hogy az illesztőprogram megpróbálná olvasni őket. 

e DMA BIDIRECTIONAL: Az API-t kétszer kell meghívni, 
először az adatok módosításának elvégzése és az esz- 
köznek való elküldése között, másodszor az eszköz 
munkájának befejezése és az adatok illesztőprogram 
által történő elérése között. 
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Egységes memóriaterület foglalása 

A legtöbb eszköz postafiók jellegű memóriaterületek 
segítségével tartja a kapcsolatot az illesztőprogrammal. 
A postafiók-memóriatartományet az illesztőprogramon kí- 
vül más általában nem használhatja. A postafiók egysé- 
gességének fenntartása az előbbi API segítségével eléggé 
nehézkes volna, ezért a rendszermag lehetőséget biztosít 
olyan memóriaterület foglalására, amelyre minden pilla- 
natban garantált az eszköz és a processzor közötti adat- 
egyezés: 


void "dma alloc coherent(struct device "dev, 
size tsize, 
5 dma addr t "physaddr, 
mint flag); 


Ezzel egy size méretű, egységes tartomány képzetes 
címét kapjuk vissza, amely egyben egy fizikai síncímmel 
(physaddr) is rendelkezik az eszköz felé. 

A flag segítségével a foglalás típusát adhatjuk meg, ez 
GFP. KERNEL (a memóriafoglalás alvó állapotba is kerülhet 
teljesítése előtt) vagy GFP. ATOMIC (a foglalás nem kerülhet 
alvó állapotba, sikertelenség esetén NULL értékkel kell 
visszatérni) lehet. Az API segítségével foglalt terület 
garantáltan folytonos a képzetes és a fizikai sínmemóriá- 
ban egyaránt. Megkötés, hogy a méretnek 128 KB alatt 
kell lennie. 

Az illesztőprogram eltávolításának részeként az egységes 
memóriaterületet a következő módon kell felszabadítani: 


void dma free coherent(struct device "dev, 
ssize tsize, 
Ssvoid "virtaddr, 
5 dma addr t "physaddr); 


Ebben az esetben size az egységes terület mérete, 
a virtaddr és a physaddr visszatérési érték pedig rendre 
képzetes processzor oldali és fizikai síncíme. 


Osszefoglalás 

Írásomban villámgyors, felületes áttekintést adtam a blok- 
kos réteg és az illesztőprogramok közötti, az eszközök 
programozását szolgáló SG listák előállítását célzó párbe- 
szédről. 

A DMA API számos egyéb hasznos összetevőt tartalmaz, 
köztük olyan API-kat, amelyek töredezéstől mentes fizikai 
memóriaterületeket kezelnek. Ha sikerült felkeltenem az 
érdeklődésedet, akkor következő lépésként a rendszermag 
Documents könyvtárának és forráskódjának tanulmányo- 
zását javaslom. 


Linux Journal 2004. május, 121. szám 


James Bottomley a SteelEye programtervezője és 
a nyílt forrású közösség aktív tagja. Ő felel a SCSI 
alrendszer, a Linux Voyager átültetés és az 53c700 
illesztőprogram karbantartásáért, továbbá DMA/ 
eszköz modellezési-elvonatkoztatási munkájával 

a PA-RISC Linux fejlesztésébe is bekapcsolódott. 








Védett processzorok: valós idejű teljesítmény 


szabványos Linux alatt 


Tartsunk fenn egy processzort a nagy fontosságú feladatok számára, és máris 
magasabb szinvonalú valós idejű szolgáltatásokat biztosíthatunk. 


többprocesszoros rendszerekben a védett pro- 
A cesszor olyan egység, amelyet a nagy fontosságú, 

valós idejű folyamatok futtatására tartanak fenn. 
A védettként kiválasztott processzor erőforrásai teljes egé- 
szében a nagy fontosságú folyamatok futtatását szolgálják. 
A védett processzorok futtatási környezete biztosítja a valós 
idejű alkalmazások üzemeltetéséhez szükséges előre jósol- 
hatóságot. 
Másként fogalmazva, ha rendelkezünk egy védett pro- 
cesszorral, akkor garantáltan gyors választ tudunk adni 
a külső megszakításokra, és előre meghatározható működé- 
sű környezetet tudunk biztosítani a valós idejű folyamatok 
futtatásához. 


linux és védettség 

Korábban védett processzort csak szimmetrikus többpro- 
cesszoros rendszerekben lehetett kijelölni. A hiperszálas 
(hyperthreading), vagyis logikailag egynél többnek látszó 
processzorok megjelenésével azonban már egyprocesszoros 
rendszerben is kijelölhetünk védett processzort. 

A védett processzoros megközelítéssel a fejlesztők a va- 

lós idejű futtatási környezetekéhez hasonló eredményeket 
érhetnek el. 

Az eredmények összehasonlíthatóak az RTAI vagy 
RT/Linux környezetben mértekkel, ahol a Linux egy valós 
idejű futtatási környezetben önálló folyamatként kel életre. 
Ha tisztán linuxos környezetet használunk az alkalmazások 
fejlesztéséhez, akkor jó néhány előnyt élvezhetünk az ilyen 
jellegű futtatási környezetekhez képest. Például a Linux 
számos illesztőprogramot támogat, így a teljes értékű alkal- 
mazási megoldások megvalósításának költsége lényegesen 
alacsonyabb. A magas szintű programozási nyelvek széles 
választékával az alkalmazások elkészítése is lényegesen ha- 
tékonyabb. 

Kereskedelmi alkalmazásoknál ez fontos tényező, és bár 

a valós idejű rendszerek tervezésénél nem feltétlenül 

a programozás hatékonysága a legfontosabb, a fejlesztési fá- 
zisban mégis komoly segítséget jelenthet, valamint a végső 
termék szolgáltatásainak bővítéséhez is hozzájárulhat. 
Mindemellett a Linux összetett protokollkészletekkel — mint 
például a CORBA -, kiterjedt grafikai képességekkel és fej- 
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1. ábra A védett processzorral és az anélkül mért válaszidők 
összehasonlítása 


lett alkalmazásfejlesztői eszközökkel rendelkezik. A normál 
Linux-terjesztésekben elérhető szolgáltatásokon túl a Linux 
tudása — köszönhetően a mögötte álló közösség erejének — 
napról napra nő. 

Ha az alkalmazások tervezésekor a Linuxot választjuk alap- 
nak, a felhasználó a jövőben lényegesen több választási le- 
hetőséggel élhet majd. 


A valós idejű működés megjósolhatóságot 

jelent, nem sebességet! 

Valós idejűnek azt az alkalmazást nevezzük, amelynek 

a külvilág eseményeire kell válaszolnia, és a műveleteket 
adott határidőn belül kell befejeznie. 

A határidő letelte után adott helyes válasz nem számít helyes 
válasznak. Maguk a határidők az alkalmazástól függnek, 
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néhány mikromásodperc és több másodperc között változ- 
hatnak. A szigorúan valós idejű alkalmazásoknál a határidő- 
ket be kell tartani. Kizárólag a rendszer által a legrosszabb 
esetben teljesített mutatók érdekelnek bennünket, ugyanis 
ezek azok az esetek, amelyekben a határidők elmulasztása 
előfordulhat. 

Mivel a való világ eseményeiről a számítógépes rendszer 
megszakítások révén értesül, egy valós idejű operációs 
rendszernek a legrosszabb esetben is adott időn belül ga- 
rantáltan válaszolnia kell a megszakításokra. 

Ha ez sikerül, és át tudjuk adni a vezérlést a megfelelő va- 
lós idejű alkalmazásnak, már meg is tettük az első lépést 

a határidő teljesítése felé. 

Ha a valós idejű alkalmazás már fut, a rendszernek elő- 

re meghatározható futási időt is garantálnia kell az alkal- 
mazás számára. Ha a valós idejű alkalmazás futtatásának 
ideje túlságosan széles tartományban ingadozik, a határ- 
időket túllépjük. 

Ha a megszakításokra jó ütemben akarunk válaszolni, 

az operációs rendszernek képesnek kell lennie arra, hogy 
megszakítás fellépése esetén bármely futó programtól azon- 
nal el tudja venni az erőforrásokat. Mivel a 2.4-es sorozatú 
Linux nem engedi a feladatoknak, hogy más, a rendszer- 
magon belül futó feladatoktól elvegyék az erőforrásokat, 
ez a sorozat legrosszabb esetben meglehetősen gyenge 
válaszidőket biztosít. Létezik persze egy folt, amely lehető- 
vé teszi a rendszermagon belül futó feladatok erőforrásai- 
nak elvételét. Sajnos ezt hiába telepítjük, maradnak olyan 
rejtett tényezők, amelyek a megszakításokra adott válaszok 
jelentős elhúzódását okozhatják. 

Az operációs rendszer feladata az, hogy több, a rend- 

A megosztott erőforrások jellemzőit tartalmazó adatszer- 
kezetek megsérülhetnek, ha egyszerre több program is 
használja őket. 

Ebből következően minden operációs rendszernek vannak 
olyan kritikus kódrészletei, amelyeket a programok csak 
egymás után érhetnek el. 

Ha egy nagy fontosságú feladat — megszakítás fellépése 
miatt — hirtelen futtathatóvá válik, a processzor nem adható 
át neki azonnal, ha az éppen futó program pont egy ilyen 
kritikus szakaszban van. 

A hosszúra nyúló kritikus szakaszok tehát jelentős mérték- 
ben befolyásolják a rendszer megszakításokra való válasz- 
adási képességeit. Az alacsony késleltetéseket biztosító fol- 
tok megfelelő algoritmusok segítségével a hosszú kritikus 
szakaszok egy részét eltüntetik a Linux rendszermagból, 
illetve lerövidítik azokat. 

Általában elmondható, hogy minél bonyolultabb egy 
alrendszer, annál hosszabbak a kritikus szakaszok. Mivel 

a Linux számos összetett alrendszert támogat, köztük fájl- 
rendszereket, hálózati és grafikai alrendszereket, kritikus 
szakaszai rendkívül hosszúak, legalábbis egy kisméretű, 
valós idejű operációs rendszerhez hasonlítva. 

Az erőforrások elvételét lehetővé tévő folt és az ala- 

csony késleltetéseket garantáló foltok jelentős mértékben 
javítottak a Linux válaszidőin. A kritikus szakaszok ennek 
ellenére több tíz msec időtartamot is felölelhetnek, már- 
pedig sok valós idejű alkalmazás számára az ilyen válasz- 
idők elfogadhatatlanok. 
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2. ábra Válaszidők (kernel.org 2.4.21-pre4) 


Mi az a védett processzor? 

Mint korábban már említettem, a védett processzort a nagy 
fontosságú feladatok futtatására és a hozzájuk tartozó meg- 
szakítások kezelésére tartjuk fenn. 

Védett processzor megadásának előfeltétele, hogy az operá- 
ciós rendszer képes legyen a folyamatok és a megszakítások 
affinitásának (futtató processzorának) beállítására. A 2.4-es 
sorozatszámú Linux képes a megszakítások affinitásának 
beállítására, és ugyanez a képessége folyamatokra a megfe- 
lelő nyílt forrású foltok segítségével biztosítható. (Lásd: 
sProcesszorhoz kötés" , Linuxvilág, 2003. szeptember). 

A védett processzor előnyei 

Mivel a védett processzorok nem futtatnak háttérfo- 
lyamatokat, a védett processzorokra kerülő nagy fontos- 
ságú feladatoknál nincs meg annak a veszélye, hogy azért 
ne tudnának válaszolni egy megszakításra, mert egy 
másik, éppen kritikus szakaszban lévő folyamat köti le 

a processzort. 

A megszakítások mindig nagyobb fontosságot kapnak, 
mint bármely folyamat, és mivel fellépésük előre nem 
jósolható meg, a nem valós idejű megszakítások jelentős 
bizonytalansági tényezőt hozhatnak a folyamatok előre 
megbecsült futtatási idejébe. 

Egy védett processzor nem foglalkozhat a megszakítá- 

sok kezelésével, hacsak az adott megszakítás nem egy 

nagy fontosságú, a védett processzorhoz rendelt feladat- 
hoz tartozik. 


Védett processzoros rendszer megvalósítása 

Ha folyamatok és megszakítások affinitását egyaránt meg 
tudjuk adni, akkor olcsón meg tudjuk oldani a kiszemelt 
processzor védelmét is. Ez a megoldás azonban csak akkor 
működőképes, ha egyik folyamat sem változtatja meg saját 
affinitását úgy, hogy a védett processzort is igénybe vegye. 
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3. ábra Válaszidők (Red Hat 8.0) 


Általánosságban tehát ennél erőteljesebb védelemre van 
szükség - alábbiakban egy ilyen megoldást fogok ismertetni. 
Processzor védelmét a /proc felületen keresztül írhatjuk elő, 
itt arendszergazda egy maszkkal választhatja ki a védett 
processzorokat, valamint egy megfelelő paranccsal a maszk 
módosítását is megoldhatja. 

A felület lehetővé teszi a processzorok dinamikusan történő 
védetté nyilvánítását. 

Ha egy processzort védettként jelölünk meg, akkor egyik 
folyamat sem módosíthatja saját affinitását úgy, hogy a vé- 
dett processzort is igénybe vegye, feltéve, hogy a tiltás fi- 
gyelembe vételével marad olyan processzor, amelyen a fo- 
lyamat futhat. 

A felhasználóknak tehát kifejezetten ki kell választaniuk 

a védett processzort folyamataik futtatására, ha igénybe 
akarják venni annak erőforrásait. 

Saját affinitásmaszkjához csak privilegizált folyamat adhat 
hozzá processzort. 

Ennél a megvalósításnál módosítani kell a folyamatok affi- 
nitását beállító programkódot. A sys. sched setaffinityO 
függvénnyel processzoraffinitást lehet beállítani. A függ- 
vény módosításával eltávolíthatjuk a védett processzort 
minden felhasználóra specifikus maszkból, amikor az 
affinitást beállítottuk : 


p-:cpus. allowed user -— new mask; 

if (new mask 8 -shielded proc) 
new mask §—- -shielded procs; 

set cpus allowed(p, new mask); 


Megjegyzem, a védett processzort jelölő bitek nem 
törlődnek, ha ezáltal a folyamat futtatása mindegyik pro- 
cesszoron tilossá válna. A cpus. allowed user egy új mező 
a task adatszerkezetben, amely az eredeti, a felhasználó ál- 
tal megadott affinitást tárolja. 
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Amikor a védett processzorok maszkja megváltozik, a fenti 
kódot a rendszer összes folyamatára meg kell hívni. 

Ehhez kell tudni a felhasználó által eredetileg beállított pro- 
cesszoraffinitást. A védett processzor maszkjának megvál- 
toztatására alkalmas kód a következőképpen néz ki: 


for each task(p) ( 
new mask - p-:cpus allowed user € 
cpu. online map; 
if (new mask g -cshielded proc) 
new mask §-— -shielded procs; 
if (new mask !- p-scpus allowed) 
set cpus allowed(p, new mask); 


Teljesítménypróbák 

A megszakításokra adott válaszok megadási idejének méré- 
sére az Andrew Morton weboldalán talált Realfeel teljesít- 
ménymérő programot használtuk. 

Azért erre a programra esett a választásunk, mert a valós 
idejű óra (Real Time Clock, RTC) illesztőprogramot használ- 
ja, és ezt több Linux-változatban is alkalmazzák megszakí- 
tások létrehozására. 

A program az RIC illesztőprogram által létrehozott meg- 
szakításra adott válaszok megadási idejét méri. Az RTC-t 
megszakítások periodikus előállítására használjuk, ponto- 
san 2048 Hz-es frekvenciával. 

Egy read rendszerhívást is támogat, amely a követ- 

kező megszakítás létrehozásakor tér vissza. A válaszidő 
mérésére az IA-32 TSC időzítőt érdemes használni, ennek 
felbontása a processzor órajelétől függ. 

A megszakításokra adott válaszok létrejöttének idejét úgy 
tudjuk mérni, hogy először kiolvassuk a TSC értékét, majd 
ismételt read hívásokat indítunk a /dev/rtc-re. 

Amikor minden read hívás véget ért, a program kiolvassa 

a TSC aktuális értékét. 

A két egymást követő TSC érték különbsége adja meg, 
hogy az RTC megszakításra várva a folyamat mennyi ideig 
volt blokkolva. A várt válaszidő 1/2048 másodperc. 

Minden a várt válaszidőn túli idő lappangási időnek számít 
a megszakítás kezelését tekintve. 

Ha mérni akarjuk, hogy legrosszabb esetben mennyi idő 
alatt válaszol a rendszer a megszakításokra, akkor aktív hát- 
térterhelést kell rónunk rá. 

A háttérterhelésnek akkorának kell lennie, hogy a rendszer 
csak késve tudjon reagálni a megszakításokra, és a futtatás 
előre jósolhatóságát rontó versengést kell okoznia az erőfor- 
rásokért. A háttérterhelés előidézésére a Red Hat stress- 
kernel csomagja tökéletesen megfelel. 

A csomagból a következő programokat választottuk ki: 
TTCB FIFOS MMAPF P3 FPU, FS és CRASHME. 

A TTCP nagyméretű adatcsomagokat küld és fogad 

a hurokeszközön keresztül. 

A FIFOS MMAP több próba kombinációja, felváltva cserél 
adatokat két folyamat között FIFO elven, illetve végez 
műveleteket egy mmap-pal kezelt fájlon. A P3 FPU próba 
lebegőpontos mátrixokon végez különféle műveleteket. 
Az FS próba egy maréknyi fájlon változatos műveleteket 
végez, például nagyméretű, középen üres fájlokat hoz lét- 
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re, majd csonkolja és bővíti ezeket. Végül a CRASHME 
próba véletlenszerű adatokat tartalmazó puffereket hoz 
létre, majd ezekre az adatokra ugrik, és megpróbálja 
futtatni őket. 

Bár Ethernet-forgalom nem keletkezik a rendszeren, a háló- 
zati kapcsolat fennmarad, és a gépnek a próbák futtatása 
közben is kezelnie kell a normál szórásos forgalmat. 

A stress-kernel csomagban szereplő NFS COMPILE próba 
egy újabb változatát használtuk, az eredeti erőforrás-felsza- 
badítási hibái miatt ugyanis a próbát nem lehetett hosszabb 
ideig futtatni. 

Az NFS COMPILE parancsfájl újra és újra lefordítja 

a rendszermagot, miközben egy a helyi hurokeszközön 
keresztül elérhetővé tett NFS fájlrendszert használ. 

A próbák futtatására egy 1 GB memóriával és SCSI me- 
revlemezzel felszerelt kétprocesszoros Pentium 4 Xeon 
gépet használtunk. 


Eredmények 

A védett processzor megszakításokra adott válaszainak ide- 
jét a Concurrent Computer Corporation által készített 
RedHawk Linux 1.3-as változata alatt mértük. A RedHawk 
2.4.21-es rendszermagra épülő Linux rendszer. Érdemes 
megjegyezni, hogy a RedHawk Linux rendszermag külön- 
leges szolgáltatásai közül csak az egyik a védett processzo- 
rok kijelölésének lehetősége. 

Az alább közölt eredmények eléréséhez - kisebb- 
nagyobb mértékben - az egyéb fejlesztések is hozzájá- 
rultak. A rendszermag például több nyílt forrású foltot 

is tartalmaz, köztük Robert Love erőforrások elvételét 
lehetővé tévő foltját, Andrew Morton alacsony késlelte- 
tést biztosító kiegészítését valamint a 2.5-ös Linux-ág O(1) 
ütemezőjét. 

A teljesítménypróbák eredményét további módosítások 
is befolyásolhatták, így például azok az algoritmus-vál- 
toztatások, amelyek a Linux rendszermag kritikus szaka- 
szainak lerövidítését szolgálják; és az, amelyik az alsóbb 
megszakítások állítható fontosságú és ütemezési házi- 
renddel szabályozható rendszermag démonon belüli 
kezelését teszi lehetővé. 


Red Hawk és Red Hat 

Az 1. ábrán látható, hogy RedHawk Linux alatt védett pro- 
cesszor használatával illetve anélkül milyen eredményeket 
sikerült elérni. A két eredmény közötti eltérés szembeszö- 
kő. A rendszer a legtöbb esetben mindkét módban keve- 
sebb mint 100 mikromásodperc alatt képes volt válaszolni 
az RTC megszakításokra. 

Általában tehát elmondható, hogy a Linux kellő gyorsa- 
sággal válaszol a megszakításokra. Csakhogy, mint már 
említettem, a valós idejű rendszereknél a legfontosabb 
mutató a legrosszabb esetben adott válaszidő. Ennek oka 
az, hogy éppen ilyenkor fordulhat elő, hogy egy valós 
idejű alkalmazás túllépi a megadott határidőt. 

Védett processzoros módban a legrosszabb esetben is 220 
mikromásodperc alatt megérkezett a válasz az RTC meg- 
szakításra. Amikor nem használtunk védett processzort, 
akkor a felső határ 10 msec volt, ami egy nagyságrenddel 
nagyobb, mint a védett processzoros mód legrosszabb 
eredménye. 
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Ugyan a válaszidő az esetek kevesebb mint egy százaléká- 
nál volt nagyobb mint 200 mikromásodperc, több ezer eset- 
ben az 500 mikromásodperc időtartamot is meghaladta. Egy 
valós idejű rendszerben ezek az esetek nagy valószínűség- 
gel egy-egy elmulasztott határidőt jelentenek. 

Ugyanezt a megszakításpróbát egy módosítások nélküli 
2.4.21-es kernel.org rendszermagon (2. ábra), valamint egy 
8.0-s Red Hat terjesztésen (3. ábra) is lefuttattuk. Ez a Red 
Hat rendszermag nem tartalmazza az erőforrások elvételét 
lehetővé tévő foltot, de az alacsony késleltetéseket biztosítót 
igen, vagyis esetében túl hosszúra nyúló kritikus szakaszok- 
ról nem beszélhetünk. 

Mivel védett processzort ezek közül a rendszermagok 
közül egyik alatt sem lehet kijelölni, esetükben eredmé- 
nyeket csak a nem védett módnál tüntettünk fel. 

Ezek a rendszermagok a RedHawk rendszermaggal mér- 
tekhez hasonló, általában 100 mikromásodperc alatti válasz- 
időket mutatnak. 

A legrosszabb eset azonban messze kedvezőtlenebb, mint 

a RedHawk Linux akár védett processzor nélküli teljesítmé- 
nye, a kernel.org Red Hawk összeállítása 107 msec, a Red 
Hat pedig 323 msec alatt válaszol, ha minden kötél szakad. 
Az eredmények cseppet sem meglepők, hiszen ezeket 

a rendszermagokat inkább az erőforrások egyenlő folya- 
matok közötti elosztására tervezték, és feladatuk inkább 
általánosan jó rendszerjellemzők, és nem valós idejű 
válaszidők biztosítása. 


Osszefoglalás 

Egyértelmű, hogy védett processzor kijelölésével jelentős 
javulást tapasztalhatunk a linuxos rendszerek legrosszabb 
esetben adott válaszidőinek tekintetében. 

A védett processzorok alkalmazása hatékony megoldás, mi- 
vel így a rendszer legfontosabb feladatai számára erőforrás- 
ok tarthatók fenn. 

Mindezt a Linux normál alkalmazásprogramozási felületé- 
nek módosítása nélkül érhetjük el. 

írásomban csak az RTC megszakításra adott válaszok- 

ról esett szó. Az RTC kiválasztását az indokolta, hogy 

a legtöbb Linux-változatban alapvető szolgáltatásnak 
számít. Más megszakításforrások és jobban optimalizált 
illesztőprogramok használatával ennél jobb garantált 
válaszidőket is el lehet érni. 

Aki szeretne részletesebben megismerkedni a védett pro- 
cesszoros megoldásokkal, illetve szeretné látni, hogy jobb 
válaszidőket garantáló illesztőprogrammal milyen eredmé- 
nyeket lehet elérni, az tanulmányozza át 

a 5 http:/www.ccur.com/isddocs/ 

wp-shielded-cpu.pdf dokumentumot. 
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Stephen Brosky a Concurrent Computer 
Corporation Integrált megoldások részlegének veze- 
tő kutatója. Tagja volt a valós idejű alkalmazás- és 
ke programszálfelületekre vonatkozó Posix 1003.1b és 
1003.1c szabványokat elkészítő IEEE bizottságnak. 








Feladat-automatizálás az Aap segítségével 


Az Aap rugalmas eszköz, amely képes mindenre, amire a make, sőt még egyébre 
is. Most megtudhatjuk, hogyan hozhatunk létre mobil megoldásokat 
a weboldalunk kezeléséhez és a programjaink lefordításához. 


okan Makefile-t, vagy héjprogramokat használnak 
S a műveletek önműködővé tételéhez, ha egy fájl vál- 

tozása valamilyen művelet végrehajtását teszi szük- 
ségessé. Elvégezzük a fájlon a kívánt módosításokat, majd 
segítségül hívjuk a make-et remélve, hogy a változtatásokkal 
kapcsolatos minden szükséges teendőt elvégeztük. Gyak- 
ran előfordul, hogy a Makefile-lal kapcsolatban cselhez kell 
folyamodnunk, és sokszor jutunk odáig, hogy a touch se- 
gítségével kell valamilyen hiányzó függőséget pótolnunk. 
Ez oda vezethet, hogy amikor mások kezébe kerül a gondo- 
san beállított Makefile-unk, nehezen tudják kibogozni, ho- 
gyan is működik. 
Az ilyen feladatok sokkal könnyebben és megbízhatóbban 
végezhetők el az Aap segítségével, mint a make-kel, sőt 
előbbi rendelkezik beépített Internet-támogatással is. 
A szükséges letöltések és feltöltések végrehajtódnak anél- 
kül, hogy erre parancsokat kellene megadnunk, vagy idő- 
bélyegző-fájlokat használnánk. A megbízhatóság forrása az 
önműködő függőség-felismerés és az aláírások használata 
az időbélyegzők helyett. Az Aap segítségével könnyebben 
adhatjuk meg az elvégzendő feladatot és így kevesebb hibát 
vétünk. Szükség esetén használhatjuk a héj parancsait is. 
Ebben a cikkben két példán keresztül világítjuk meg az Aap 
működését: az első egy weboldal kezelése, a második pedig 
egy program lefordítása. 


Az Ahap telepítése 

Az Aap használatához szükségünk van a Python 1.5-ös vagy 
újabb változatára. Ha abban a valószínűtlen helyzetben va- 
gyunk, hogy nincs Python a rendszerünkön, töltsük le 

a 5 httoNMwww.Python.org oldalról, telepítsük a Linux 
rendszerünk telepítőlemezéről, vagy frissítsük a rendsze- 
rünket. Az Aap telepítése négy egyszerű lépésben elvégez- 
hető. Kezdjük a legfrissebb Aap.zip csomag letöltésével 
(lásd a hálózatos Resources — források részt), ezután bont- 
suk ki a csomagot egy ideiglenes könyvtárba (unzip aap- 
1.53.zip). 

Ha root-ként jelentkeztünk be, futtassuk az ./aap install 
programot. Ha közönséges felhasználók vagyunk, telepít- 
sük a programot a saját könyvtárunkba az ./aap install 
PREFIX-$HOME paranccsal. Az Aap egy GNU GPL licenc alatt 
terjesztett nyílt forráskódú program. 


www.linuxvilag.hu 


Egy weboldal karbantartása 

A friss Aap programmal felvértezve vágjunk bele az ismer- 
kedésbe, és egy példafeladaton keresztül vizsgáljuk meg 

a program használatát. Korábban létrehoztunk egy egysze- 
rű weboldalt HTML fájlokkal és képekkel. A fájlok jelen- 
leg a helyi gépünkön vannak, fel kellene tölteni azokat 

a webkiszolgálóra. Az 1. listán láthatjuk azt az Aap-receptet, 
amely elvégzi ezt a feladatot. Receptnek az Aap parancsfájl- 
jait nevezzük. 

Mentsük ezt a parancsfájlt main.aap néven. Ez az a fájl, 
aminek a létrehozása a Makefile feladata: az alapértelme- 
zett esetben futtatandó fájl. Az aap paraméterek nélküli fut- 
tatása az aktuális könyvtárban lévő main.aap fájl végrehaj- 
tását eredményezi. 

Egy Aap-receptben lévő megjegyzések kettős kereszttel () 
kezdődnek és a sor végéig tartanak, éppen úgy, mint egy 
Makefile vagy héjprogram esetén. A recept első végrehaj- 
tandó sora egy értékadás: a Files változóhoz hozzárende- 
lődik a feltöltendő fájlok listája. Nincsenek perjelek vagy az 
értékadás végét jelző egyéb írásjelek, az Aap a parancs foly- 
tatását a használt behúzás mértékéből ismeri fel. Ez első pil- 
lantásra furcsa lehet, de hamar hozzá lehet szokni. Ezzel az 
eljárással kiküszöbölhetjük az írásjelek használatából adódó 
hibalehetőséget és kényszerítjük magunkat a könnyen ol- 
vasható külalak használatára. A sorok behúzására használ- 
hatjuk a szóközt és a TAB billentyűt egyaránt. 

Az :attr kulcsszóval kezdődő sor egy Aap-parancs. Minden 
Aap-parancs kettősponttal kezdődik, így könnyen felismer- 
hető. Ez a parancs a publish tulajdonságot rendeli a meg- 
adott paramétereihez, ez határozza meg a fájlok feltöltésé- 
nek a helyét, amikor azok közzétételre kerülnek. Az itt 
használt eljárás az scp://, a secure copy (biztonságos máso- 
lás). Az rsync:// és az ftp:// a másik két támogatott eljárás. Az 
:attr parancs utolsó paramétere a $Fi les, a Files változó 
értéke. A tulajdonság a $Files minden egyes eleméhez 
hozzárendelődik. 

Amikor az Aap-t paraméter nélkül futtatjuk, az al] célob- 
jektum által meghatározott elemeket frissíti. Az utolsó sor 
azt határozza meg, hogy az alapértelmezett all célobjektum 
a publish tulajdonságtól függjön. Ez egy speciális célobjek- 
tum, amely arra utasítja az Aap-t, hogy azokat a tételeket 
töltse fel, amelyek publish tulajdonsággal rendelkeznek. 
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Most már szerkeszthetjük a HTML-fájljainkat, képeket ad- 
hatunk hozzájuk és nézegethetjük az eredményt a saját gé- 
pünkön. Amikor elégedettek vagyunk az eredménnyel, fut- 
tathatjuk az aap-t. Az Aap észleli, hogy mely fájlok változtak 
meg és feltölti azokat. Ehhez aláírásokat (ellenőrző összege- 
ket) használ, így ha egy fájl korábbi változatát állítjuk 
vissza, akkor is megfelelően működik. Ha a make-et hasz- 
nálnánk, a visszaállított fájlhoz is hozzá kellene nyúlnunk, 
hogy beállítsuk az időbélyegzőjét. 

Ha ki szeretnénk próbálni ezt a példát, de nincs olyan ki- 
szolgálónk, ahova feltölthetnénk az anyagot, használhatjuk 
a file:/tmp/htm1/96fi1e9 kifejezést a publish tulajdonság 
beállításánál. Ebben az esetben az aap szükség esetén létre- 
hozza a /tmp/html könyvtárt. Egy figyelmeztetés: az Aap 
nem törli a kiszolgálóról a már nem használt fájlokat. Ezt 

a make sem teszi meg nekünk. Saját magunknak kell a tör- 
lést kézzel elvégeznünk. Remélhetőleg az Aap rövid időn 
belül kiegészül az önműködő törlés lehetőségével is. 


A képfájlok listázása 

A képek kiválasztásánál használtunk egy dzsókerkaraktert: 
images/".png. Ez ugyan kényelmes, de magában rejti azt 

a veszélyt, hogy olyan képek is felkerülnek, amelyeket nem 
akarunk feltölteni. Minden egyes fájl megnevezésével elke- 
rülhető ez a csapda, de így a felsorolásból könnyen kifelejt- 
hetünk valamit. Mivel ez egy elég általános probléma, az 
Aap egy függvényt biztosít a képek fájlneveinek a HTML- 
fájlokból történő kiszűrésére. A 2. lista mutatja ennek 

a módját. A get html images Python-függvényt hívjuk se- 
gítségül, az aposztrofok között egy Python-kifejezés szere- 
pel. Az Aap kiértékeli a kifejezést, majd az eredményt, 

a képfájlok neveit, berakja a helyükre. 

Aget html imagesO függvénynek vannak azonban 
korlátai is: csak tiszta HTML-fájlokkal képes dolgozni, ame- 
lyekben a képek relatív elérési útvonallal rendelkeznek. 


HTML-fájlok előállítása 

A legtöbb HTML-fájl fejrészből, címből, törzsrészből és láb- 
részből áll. Nyilvánvaló, hogy nem akarjuk minden egyes 
alkalommal újra begépelni a közös részeket. Egyszerű meg- 
oldás a több fájlból történő összetűzés. A 3. lista az ezt meg- 
valósító receptet mutatja. Öt részt használunk: header (fej- 
rész), title (cím), middle (középrész), contents (tartalom), 
és footer (lábrész). A cím és a tartalom minden oldalon kü- 
lönböznek, de a másik három rész megegyezik. 

A 2. és 3. lista közti lényeges eltérés a 3. listában hozzáadott 
: rule parancs. Ez azt meghatározza, hogy a célobjektum 

(a HTML-fájl) öt forrásfájltól függ, és a parancs ezeket so- 
rolja fel, aminek alapján a forrásfájlokból előáll a célfájl. 

A 9 jel a fájl neve helyett használatos, hasonlóan a " 
dzsókerkarakterhez. A rule parancs minden 90-jele ugyan- 
azt a nevet helyettesíti, így az index.html előállításakor az 
index szó helyett használatos. A forrásfájlok közt foglal he- 
lyet tehát az index title.part és az index.part fájl. A : rule 
sora alatt azoknak a parancsoknak a — behúzott formában 
lévő -— felsorolása következik, amelyek akkor futnak le, ami- 
kor a rule parancs célpontjának frissítése szükségessé válik. 
Vagyis a recept két szintre bomlik: a felső szinten lévő paran- 
csok akkor futnak le, amikor a recept olvasásra kerül, a rule- 
parancsblokk pedig később, amikor szükségessé válik. 
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1. lista Recept fájlok webkiszolgálóra való feltöltésére 


ff A feltöltendő fájlok listája. 
Files -— index.html 
info.htm1 
download.htm! 
images/" .png 


tt A publish tulajdonság jelzi a feltöltés 
ft helyét. 
sat tdúbÜ TÉS hő 
5 scp://my. server .net/htm1/9fi1e93 
$Files 


ft Amikor target (cél) meghatározása nélkül 
tt futtatjuk: nyilvánossá teszi a fájlokat. 
edlhiKS gp úbiikésh 


2. lista A képek fájlneveinek kinyerése a HTML-fájlból 


tf A feltöltendő fájlok listája. 
Files -— index.html 

info.htm1 

download.htm! 
Files 4—- get html images(Files)" 


ff A publish tulajdonság jelzi a feltöltés 
t helyét. 
Sater DUD ShsE 
5 scp://my. server .net/htm1/9őfi1e963 
$Files 


ft Amikor target (cél) meghatározása nélkül 
ft futtatjuk: nyilvánossá teszi a fájlokat. 
ale kpúbikish 


A :cat parancs összefűzi a fájlokat, hasonlóan a UNIX cat 
parancsához. Valójában ennél sokkal többre képes, például 
egy megadott címről történő fájlbeolvasásra. A rule pa- 
rancsban a $source a forrásfájlok teljes listáját jelenti. 

A HTML-fájlokat létre kell hoznunk, még mielőtt kinyer- 
nénk a bennük szereplő képfájlok listáját. Ehhez az : update 
parancsot kell segítségül hívnunk a get. html. images O 
függvény hívását megelőzően. Ennek hatására a megadott 
szabály alapján megtörténik a HIML-fájlok frissítése. Ez 

a parancs a recept felső szintjén foglal helyet, vagyis mindig 
végrehajtódik, amikor az Aap olvassa a receptet. 

Most, hogy ennyi fájlunk van, honnan fogja az Aap tudni, 
hogy milyen tennivalókat kell végrehajtania? Az Aap erre 

a függőségeket használja, akárcsak a make. Azzal a célobjek- 
tummal kezdi, amit a parancssorban megadunk, ha nem 
adunk meg semmit, akkor az a11 (minden) a feltételezett 
cél. Az Aap ezután megkeresi azokat a függőségeket és sza- 
bályokat, amelyekben ez a cél megjelenik a kettőspont előtt. 
A kettőspont lényegében a függést jelenti, a kettőspont 











3. lista HTML fájl létrehozása öt részből 


Files -— index.html 
info.html 
download.htmi 

:rule 2.html : header.part 

9 title.part 
middle.part 
9.part 

footer.part 

:cat $source 5! $target 


:update $Files 
Files 4— get html images(Files) 


slag E DÜDINT Sh 
5 scp://my . server .net/htm1/9őfi1e93 
$Files 


all : publish 


után helyezkednek el azok a forrásfájlok, amelyektől a cél 
függ. Ezután ezeket a forrásfájlokat vizsgálja meg az Aap és 
megkeresi az összes olyan szabályt, amelyben ezek célként 
szerepelnek. A folyamat rekurzívan folytatódik mindaddig, 
amíg el nem fogynak a szabályok. Az eredmény egy függő- 
ségekből álló faszerkezet. Az Aap ezután a fa végétől (a leg- 
mélyebb résztől) kezdve lefuttatja azokat a parancsokat, 
amelyek ennek a függőségi rendszernek a felépítéséhez 
szükségesek. Kicsit bonyolultnak tűnik, igaz? Mivel azon- 
ban az Aap elvégzi ezeket a teendőket, nekünk nincs más 
dolgunk, mint hogy minden egyes célnál megadjuk, hogy 
milyen forrásoktól áll függésben. Az Aap ezután már el tud- 
ja dönteni, mi a teendő. 


Időbélyegző létrehozása 

Egy hasznos kiegészítésként adjunk időbélyegzőt is 

a HTML-tájlhoz, így a weboldalon láthatóvá válik, hogy mi- 
kor volt az oldal legutoljára frissítve. Írjuk be valahova a fájl 
lábrészébe (footer.part) a GTIMESTAMPG karakterláncot. 

A 4. lista mutatja azt a szabályt, amelynek alapján ez a ka- 
rakterlánc az aktuális dátummal lesz helyettesítve. A recept 
többi része ugyanaz, mint a 3. listában. Az :eval parancs ki- 
értékeli a Python-kifejezést, amelyben a string. replace 
egy szabályos Python-függvény egy karakterlánc másikkal 
való kicserélésére. Ezzel a módszerrel bármilyen Python- 
kifejezést használhatunk a szöveg szűrésére. A HTML-oldal 
épp úgy halad át az :eval parancs csővezetékén, mintha 

a héj alól tennénk ugyanezt. A szabály használatának első 
alkalmával minden HTML-fájl frissítésre kerül. Ennek oka, 
hogy az Aap megjegyzi a parancsok aláírását, emiatt egy 
receptben történt változtatás után nem kell foglalkoznunk 
a fájlok újbóli előállításának végrehajtatásával. 


Feltöltés az rsync segítségével 


Amikor egy honlapon valamilyen kis módosítást eszközö- 
lünk, nem túl gazdaságos teljes fájlt feltölteni. 
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4. lista Szabály a létrehozott HTML-fájl 
időbélyegzővel történő ellátására 


:rule 9.htm] : header.part 

27.-title.part 

middle.part 

76.part 

footer.part 
:print Generating $-target 
:cat $source 

] :eval string.replace(stdin, 
5 "(ATIMESTAMPA", . no.DATESTR) 


5! $target 


A feltöltés hatékony módszere az rsync segítségével valósít- 
ható meg, amely a fájlnak csak azokat a részeit tölti fel, ame- 
lyek megváltoztak. Az Aap akkor alkalmazza az rsync-et, ha 
a publish tulajdonságban megtalálja az rsync: // beállítást. 
Alapértelmezésben az rsync SSH-kapcsolaton keresztül 
kommunikál, ezt a beállítást a $RSYNC változó megváltozta- 
tásával módosíthatjuk. Az rsync nem szabványos parancs, 
amennyiben nincs a rendszerünkre telepítve, részünk lehet 
az Aap egy hasznos szolgáltatásában: a program választási 
lehetőségként felajánlja az rsync telepítését. 


70 aap 
Aap: Uploading [index.html] to 


rsync://my . server .net/html/index.htm! 
Cannot find package "rsync"! 

1. Let Aap attempt installing the package 
2. Retry (install it yourself first) 

g. Ouit 

choice: 


Az Aap rendelkezik a programtelepítés képességével, éss ha 
szükséges, az Aap honlapjáról még recept letöltésére is ké- 
pes, amely leírja az adott program telepítésének módját. Itt 
kapóra jön az Aap letöltési képessége. 


Programfordítás az Aap-vel 

Az Aap támogatja a C vagy C--- forráskódból történő for- 

dítást is. Íme egy egysoros recept, amely lefordítja a négy 

C forrásfájlból álló myprog nevű programot: 

:program myprog : main.c common.c various.c args.Cc 

A recept egyszerűsége ellenére az Aap gondoskodik az 

alábbiakról: 

e — A függőségeket önműködően feltérképezi. Nincs szük- 
ség a befoglalandó fejállomány megadására vagy a make 
depend parancs futtatására. 

e A recept a legtöbb rendszeren módosítás nélkül működik. 
Az Aap megkeresi a használandó fordító és összefűző 
programot és meghatározza a szükséges paramétereket. 

e Az objektumfájlok minden egyes rendszer esetén külön 
könyvtárban tárolódnak, így több változatot is fordítha- 
tunk anélkül, hogy az előzőt el kellene távolítanunk. 
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e Az Aap létrehoz egy naplófájlt, az AAPDIR/log fájlt, 
amely a végrehajtott műveleteket részletezi. Ha a fordí- 
tásunk nem sikerül és a kimenet már nem látszik a kép- 
ernyőn, nincs szükség arra, hogy a kimenet átirányításá- 
val újrafuttassuk a fordítást. 

e Néhány alapértelmezett cél önműködően létrejön: az 
aap install! telepíti a programot, míg az aap clean törli 
a létrehozott fájlokat. 


Ugyanezt a munkát a make-kel is elvégezhetnénk, de 
a Makefile sokkal hosszabb lenne. 


Változatok létrehozása a fordításkor 

Most hozzuk létre egy program két változatát, egy kiadásra 
szánt verziót, egyet pedig hibakeresés céljából. Az Aap tá- 
mogatja a különféle változatok létrehozását. Mindössze azt 
kell megadnunk, hogy milyen változatokra lesz szüksé- 
günk, és mi különbözteti meg ezeket egymástól. Az 5. lista 
mutatja a szóban forgó receptet. Az első sor, a :variant pa- 
rancs meghatározza a változat nevét, amelyre a fordításkor 
hivatkozhatunk. Ezt a változót parancssorban állíthatjuk be; 
az aap Build-debug a hibakereső változatot adja. Ha nem 
adunk meg paramétert, akkor a nyilvános változat készül 
el, mivel az szerepel először. A behúzás mértéke azonosítja 
a :variant parancs további részeit. A lehetséges értékek be- 
húzása kicsit kisebb, az egyes értékeknél használt paran- 
csok nagyobb behúzással szerepelnek. Az egyes részek il- 
lesztése kötelező, ezzel az olvasás is könnyebbé válik. A 
release változat beállítja az OPTIMIZE változót. Ez egy nul- 
lától kilencig terjedő szám lehet, ami az optimalizálás szint- 
jét határozza meg. Ez önműködően beállítja a használt for- 
dítóprogram megfelelő paraméterét. A debug változat 

a DEBUG változót yes értékre állítja. Az alapértelmezett érték 
no. A Target változó az eredményként kapott program ne- 
vét tartalmazza. A két változat különböző nevet használ, 
így mindkét program létezhet egy időben. A változatok 
ilyen módon való használatának nagy előnye, hogy az ob- 
jektumfájlok minden változathoz önműködően külön 
könyvtárban tárolódnak. Amikor átváltunk a két változat 
között, nem szabad elfelejtenünk, hogy az Aap nem hoz lét- 
re újra minden fájlt. 


Fordítás más nyelvből 

Ha nem C vagy C-t nyelvű kódot szeretnénk fordítani, 
szükség van a megfelelő nyelvmodul importálására. Né- 
hány alapmodult már az Aap is magában foglal. Például 
a következőképpen fordíthatunk le D nyelvű forráskódot 
(a D egy új programozási nyelv): 


:import d 
:program myprog : main.d common.d various.d args.d 
Az :import d parancs a D nyelv támogatásának betöltésére 
szolgál. Ettől eltekintve a folyamat hasonló a C-források for- 
dításához. Saját magunk is írhatunk olyan modult, amely 
megteremti egy nyelv támogatottságát. Mivel az Aap nyílt 
forráskódú alkalmazás, nyugodtan átadhatjuk a modult az 
Aap részeként való terjesztésre. Amíg ez megtörténik, he- 
lyezzük el a fájlt az Aap modulkönyvtárába, amely bővít- 
ményként működik. 
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5. lista Kibocsátársa és hibakeresésre szánt 
változatok fordítása 


:variant Build 
release 
OPTIMIZE -— 4 
Target - myprog 


debug 
DEBUG -— yes 
Target - myprogd 


:program $Target : main.c common.c various.Cc 


srargsze 


6. Lista Az Aap használata a make helyettesítésére. 


all : hello 
ft A hello program manuális fordítása 
hello : hello.c 

isys cc -o $target $source 


f Egy C program előállításának nehézkes módja. 
hello. c: 
:print Generating 
:print 5! $target 
:print 55 $target 
$target 
$target 
$target 3 


$target 
$(GDinclude $(O)stdio.h$(:) 
mainO ( 
printf("Hello world! im"); 
return 0; 


"PETE Sz 
epedés 
Dnes 


Egy KDE-alkalmazás fordítása 

Egy KDE-alkalmazás lefordítása egy csomó eszköz használa- 
tát vonja maga után, például a Ot Designer alkalmazását 

a párbeszédablakok létrehozására, a fejállományok létrehozá- 
sát a felhasználói felület leírásaiból és a folyamatközi kommu- 
nikáció kódjának előállítását. Mindezek ellenére egy KDE- 
program lefordítását végző recept is lehet ilyen egyszerű: 


:import kde 
:program logger : main.cpp 
logwidget.ui 
dcop.h (ffiletype - 
ívar OBJSUF - 


skel3 
-skel.o3 


A három bemeneti fájl közül a main . cpp közvetlenül lefor- 
dítható. A Ot Designer logwidget.ui nevű fájlját először az 
uic használatával kell feldolgozni, melynek során létrejön 
egy include-fájl, ezután pedig a moc-ot kell használni. Az 
Aap felismeri az .wi kiterjesztést és odafigyel minderre. Az 
ilyen többlépcsős fordítófolyamat-kezelés, amely során elő- 
ször az ui-fájlból h-, majd ebből moc- és objektumfájl jön 
létre, az Aap rendkívül hasznos szolgáltatása. Ugyanennek 
a Makefile segítségével történő végrehajtása sokkal több 
explicit szabályt igényel. A dcop.h fájl különleges KDE- 
elemeket tartalmaz, de normál kiterjesztéssel rendelkezik, 











7. lista A Python használata a fájlnévlisa előállítására. 
LASTPATCH - 144 


f A foltok fájlneveinek előállítása. 
apatches — 

efor i in range(1i, int(LASTPATCH) - 1): 
a Patches — Patches - ("6.2.403d " 2 i) 


ft Alapértelmezett target (cél): minden foltot 
$ alkalmazunk. 
all: done/$"Patches 


ft A két könyvtár létezésének biztosítása. . 
:mkdir íf(forcel patches done 


$ szabály a folt alkalmazására. 
:rule done/2 : patches/9 (fetch -— 
5 ftp://ftp.vim.org/pub/vim/9fi1e93 


isys patch c $source 
:touch $target 


ezért önműködően nem ismerhető fel. Ez az oka, hogy 

a fájltípus tulajdonságát be kellett állítani. A :program pa- 
rancsnak szintén tudnia kell az objektumfájl nevét, ezt adja 
meg a var. OBISUF tulajdonság. 

A használt KDE-eszközöket nem kell külön megadnunk, 
ezt az összetettséget a KDE modulfájl rejti el aszemünk 
elől. Ez sokkal kevésbé bonyolult, mint az automake 
használata. 


Az hap használata a make helyett 

Idáig olyan magas szintű Aap-parancsokat használtunk, 
amelyekkel gyorsan megadhatóak a szükséges teendők. 

A nem szabványos feladatok végrehajtásához pontosan 
meg kell határoznunk a függőségeket és a végrehajtandó 
parancsokat. Ez nagyjából úgy működik, mint egy 
Makefile. A héjparancsok mellett használhatunk hordoz- 
ható Aap-parancsokat is. Ha ez sem elég, a Python parancs- 
fájlok is rendelkezésünkre állnak. 

A 6. lista mutatja, hogy miképpen fest egy ilyen alacsony 
szintű recept. Ebben minden függőséget pontosan meghatá- 
roztunk - az al1 a hel1o-tól függ, a hello a hello.c fájlból 
fordítódik, a hello.c pedig az alapoktól jön létre lépésenként. 
Mivel egy receptben a fordítóparancsok Aap-parancsok, 

a héjparancsok futtatásához szükség van a : sys használatá- 
ra. A példában szereplő :sys cca CC fordítóprogramot fut- 
tatja. A héjparancsok használatával tehát csökken a recep- 
tek hordozhatósága. A hello.c fájl :print parancsok haszná- 
latával jön létre. 

Az első sor a 5! $target kifejezést használja, amely felülírja 
az esetleg már létező hello. c fájlt. A felkiáltójel nélkül csak 
egy hibaüzenetet kapnánk, amely a fájl létezéséről tájékoz- 
tatna. Ugyanez a sor tartalmazza a $(t) kifejezést is, amely 
megváltoztatja a it karakter megjegyzés kezdetét jelző kü- 
lönleges jelentését. Ugyanígy a $(2) és $(-) kifejezésekkel 
kapjuk meg a c és : karaktereket az átirányítás helyett. 
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A hello. c fájl létrejön, ha még nem létezne, nincs semmi- 
lyen forrásfájl-függőség megadva. A fájl egy másik helyzet- 
ben is újragenerálódhat: amennyiben valamelyik :print 
parancs megváltozik, mivel ez megváltoztatja a fordítópa- 
rancsok aláírását. Amennyiben ezek a parancsok megvál- 
toznak, az Aap tudja, hogy a célfájlt újra létre kell hozni. 

A fájlt Aap-parancsokkal hozzuk létre, nincs szükség héjpa- 
rancsok használatára. A receptnek ez a része ezért bármi- 
lyen rendszeren használható. 

Az Aap-parancsok száma azonban korlátozott. Ha további 
szolgáltatásokra van szükségünk de a hordozhatóságot is 
meg szeretnénk őrizni, a Python parancsfájlok állnak ren- 
delkezésünkre. Az Aap-receptek minden forgalomvezérlési 
megoldása a Pythonra épül. A 7. listán láthatunk egy példát 
egy receptre, amely a Vim foltjait telepíti. 

Egy ciklust használunk a foltok fájlnévlistájának előállításá- 
ra a vim-6.2.001-től kezdődően és az utolsó foltszámmal 
bezárólag, amelyet a LASTPATCH változó ad meg. Minden 
egyes foltot le kell tölteni és telepíteni. A done/$"Patches 
kifejezés $" jele az rc-stílusú változókiterjesztésre utal, 

a done/ a Patches minden eleme elé beszúrásra kerül. 
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Programcsomagy telepítése 

Korábban említettük, hogy az Aap képes az rsync telepíté- 
sére, ha az nincs fenn a rendszerünkön. A csomagtelepítő 
folyamat közvetlenül is hívható. Például az Agide telepíté- 
séhez az aap --instal1 agide parancsot használhatjuk. Az 
Agide az A-A-P GUI IDE, az A-A-P projekt egy másik része, 
amelyet programok fordítására és hibakeresésre használha- 
tunk a Vim és gdb segítségével. 

Bár még a fejlesztés korai szakaszában van, már most elég 
jó arra, hogy C programokat fejlesszünk és teszteljünk vele. 
Számos csomag már most elérhető és az idő múlásával egy- 
re több válik azzá. 

A csomagok aktuális listája elérhető a 5 http://www.a-a-p.org/ 
packages.html oldalon. Az Aap maga is telepíthető. A leg- 
frissebb változatra való frissítés az aap --insta1l1 aap pa- 
ranccsal végezhető el. Ha a rendszerünk rendelkezik cso- 
magkezelővel, valószínűleg jobban járunk, ha azt hasz- 
náljuk. 


Osszegzés 

E cikkből képet kaphattunk arról, hogy milyen feladatokat 
tehetünk önműködővé az Aap segítségével. 

A kísérletezés során rengeteg segítséget találhatunk az igen 
alapos súgóban, amely különböző formátumokban letölthe- 
tő az Aap honlapjáról (lásd a cikkhez kapcsolódó címeket). 
Ezeken az oldalakon rengeteg olyan dolognak a leírását 
megtalálhatjuk, amire ebben a cikkben nem tudtunk kitér- 
ni, ilyen például a CVS használata a változatkezelésre, az 
önműködő beállítás és sok más. 


Linux Journal 2004. május, 121. szám 


Bram Moolenaar az Aap projektvezetője és fő fej- 
lesztője. Leginkább a Vim szerkesztőprogramon 
végzett fejlesztőmunkájáról ismert. Bram Aap-n 
végzett munkáját a Stichting NLnet támogatta 
(wwvv.NLnet.n]). A honlapját a www.Moolenaar.net 
címen találjuk meg. 
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udev - állandó eszköznevek a felhasználói térben 


Vessünk véget major és minor számok okozta kavalkádnak! 


2.5-ös rendszermagtól kezdve, a rendszer minden 
A fizikai és virtuális eszköze a felhasználói térből is 

látható, és a sysfs hierarchikus szerkezeten ke- 
resztül érhető el. Az /sbin/hotplug segítségével figyelmezte- 
tést kaphatunk, ha a rendszer új eszközzel bővül vagy eltá- 
volítottuk valamelyiket. E két lehetőség használatával végre 
dinamikus, rugalmas eszközneveket használó /dev rend- 
szert hozhatunk létre. 
Cikkünk témája az udev program, amely a devfs feladatait 
vállalja át. Ez a megoldás bármely pillanatban képes a rend- 
szer eszközeihez /dev bejegyzéseket szolgáltatni. Továbbá 
olyan képességekkel is rendelkezik, amelyeket ezidáig kizá- 
rólag a devfs segítségével nem lehetett megvalósítani: ké- 
pes az eszköznevek folyamatos megőrzésére, mialatt az esz- 
köz szabadon mozoghat az eszközfában, rugalmas eszköz 
elnevezési megoldásra, figyelmeztet ha az eszköz külső 
rendszerei megváltoznak, valamint a teljes névkiosztási sza- 
bályrendszert a rendszermagon kívülre helyezi. 
A Linux gépeken a rendszer valamennyi eszközállományát 
a /dev könyvtárban találjuk. Az eszközállomány adja meg, 
hogyan érhet el a felhasználói program egy bizonyos alkat- 
részt vagy függvényt. Például, a /dev/hda állományt hagyo- 
mány szerint a rendszer első IDE meghajtójának elnevezé- 
sére használjuk. A hda név megfeleltethető egy major és 
minor számnak, melyek alapján a rendszermag meg tudja 
állapítani, melyik alkatrésszel vegye fel a kapcsolatot. Jelen- 
leg rengeteg nevet alkalmazunk, melyek a különféle major 
és minor számoknak felelnek meg. 
Minden egyes major és minor számpárhoz valamilyen nevet 
rendelünk ami az adott alkatrésztípushoz tartozik. Ezt a hoz- 
zárendelést a Linux , assigned names and numbers authority" 
szervezete (röviden LANANA, magyarul , Linux név és szám 
összerendelési hivatal") végzi, melynek jelenlegi eszközlistá- 
ját a honlapján találjuk (lásd a hálózati forrásokat). 
Ahogy a linux kezdett újfajta eszközöket is támogatni, eze- 
ket is major és minor számtartományokhoz kellett rendelni, 
hogy aztán a felhasználók a /dev könyvtáron keresztül elér- 
hessék azokat. Alternatív megoldásként az eszközöket elér- 
hetjük a fájlrendszeren keresztül is (lásd a hálózati forráso- 
kat). A 2.4-es és korábbi verzióban a major számok érvényes 
tartománya 1-255-ig terjedt, míg a minor számok 1-255 kö- 
zött lehettek. A korlátozott tartományok miatt, az új major 
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és minor számok kiosztását a 2.3-as fejlesztési ciklus idejére 
befagyasztották. Azóta a zárlatot már feloldották és a 2.6-os 
rendszermag érvényes major számtartományát 4,095-re nö- 
velték. Egyazon major számhoz pedig több mint egymillió 
minor szám rendelhető. 


Melyik /dev bejegyzés melyik eszköz? 

Amikor a rendszermag egy új eszköztípust talál, általában az 
eszköztípushoz tartozó következő major/minor párost osztja 
ki. Így aztán rendszerindításkor az első felderített USB 
nyomtató kapná a 180-as major számot és a 0-s minor szá- 
mot, amire a /dev könyvtár alatt a /dev/usb/IpO hivatkozik. 

A második USB nyomtató a 180-as major számot és az 1-es 
minor számot kapná, amit a /dev alatt a /dev/usb/lp1 azono- 
sít. Ha a felhasználó újraszervezi az USB hálózatot, esetleg 
behelyez egy új USB elosztót, hogy több USB eszközt kezel- 
hessen a rendszeren, a számítógép következő indításakor 

a nyomtatók USB keresési sorrendje megváltozhat, megcse- 
rélve ezzel a két nyomtató minor szám hozzárendelést. 
Ugyanez érvényes szinte minden eszközre melyet a számí- 
tógép működése közben eltávolíthatunk vagy behelyezhe- 
tünk. A hot-plug rendszerű PCI megoldások és buszok meg- 
jelenésével (ilyen például az IEEE1394, USB és a CardBus), 
majdhogynem minden eszköz szembekerül ezzel a problé- 
mával. 

A 2.5-ös rendszermag megjelenésével jelentősen leegysze- 
rűsödött annak megállapítása, melyik eszköz minor számát 
rendeltük melyik fizikai eszközhöz. Ha egy rendszerhez két 
USB nyomtatót csatlakoztattunk, a sysfs /sys/class/usb al- 
könyvtár szerkezete a következőképpen néz ki: 


/sys/class/usb/ 

1-- 1po 

I ]1-- dev 

I ]1-- device -s 

5. ./../../devices/pci0/00:09.0/usb1/1-1/1-1:0 

I "-- driver -s ../../../bus/usb/drivers/usblp 

"-- 1pl 
Es 
]-- device -5 

../..7/ . . /devices/pci0/00:0d.0/usb3/3-1/3-1:0 
"-- driver -s ../..7../bus/usb/drivers/usblp 


dev 











$ cat /sys/class/usb/1p0/device/serial 
HXOLL0012202323480 
$ cat /sys/class/usb/1pl/device/serial 
wOo9090207101241330 


Az egyes USB eszközkönyvtárakon belül, amelyekre az 
lp0/device és az Ip1/device közvetett hivatkozások mutatnak, 
számos USB-vel kapcsolatos információt találunk, ilyen pél- 
dául a gyártó azonosítója valamint a (remélhetőleg egyedi) 
sorozatszám. Amint az a fenti meghatározás állományaiból 
kiderül, a /dev/usb/lp0 eszközállomány a HXOLLO012202323480 
sorozatszámú USB nyomtatóhoz tartozik, míg a /dev/usb/lp1 
eszközállomány a W0O9090207101241330 számú nyomtatónak 
felel meg. Ha ezeket áthelyezzük, például mindkettőt egy 
USB elosztó mögé rakjuk, könnyen előfordulhat, hogy átne- 
veződnek, hiszen induláskor más sorrendben próbáljuk őket 
elérni: 


$ tree /sys/class/usb/ 
/sys/class/usb/ 
1-- 1po 
I ]-- dev 
I ]1-- device -s 
. ./../ . ./devices/pci0/00:09.0/usb1/1-1/1-1.1/ 
61-1.1:0 
I "-- driver -s ../..7/../bus/usb/drivers/usblp 
"-- 1pl 
]1-- dev 
device -5 
. ./. ./ . ./devices/pci0/00:09.0/usb1/1-1/1-1.4/ 
51-1.4:0 
"-- driver -s ../../../bus/usb/drivers/usblp 


$ cat /sys/class/usb/1pO0/device/serial 
wOo9090207101241330 
$ cat /sys/class/usb/1pl/device/serial 
HXOLL0012202323480 


Mint a leírásból is látszik, az eltérő próbálkozási 

sorrend következtében a /dev/usb/lp0 eszköz most 

a W0O9090207101241330 sorozatszámú USB nyomtatóhoz 
tartozik. A sysfs segítségével viszont a felhasználó meg 
tudja állapítani, hogy a rendszermag melyik eszközhöz me- 
lyik eszközfájlt rendelte. Ez pedig nagyon hatékony össze- 
rendelés, amit azelőtt nem lehetett egyszerűen megoldani. 
Mindazonáltal a felhasználót általában nem érdekli, hogy 
a /dev/usb/tIp0O és a /dev/usb/lp1 felcserélődött, és most ezért 
valamilyen beállításfájlban meg kéne változtatni valamit. 
A felhasználó mindössze annyit szeretne, hogy a helyes 
nyomtatóra nyomtasson, függetlenül attól, hogy az hol he- 
lyezkedik el éppen az USB fán. 


Túlméretes /dev 

A legtöbb terjesztésben a /dev könyvtár nem minden 
eszközállományához tartozik ténylegesen a géphez 
csatlakoztatott fizikai eszköz. A /dev könyvtár ugyanis 

az operációs rendszer telepítésekor jön létre, amikor 
belekerül az összes ismert név. Egy Red Hat Fedora 1 
verziót futtató gépen a /dev könyvtár nem kevesebb 

mint 18,000 különféle bejegyzést tartalmaz. Ilyen mennyi- 
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ségű bejegyzés hamar kényelmetlenné válik, ha a felhasz- 
náló meg szeretné állapítani, milyen eszközök vannak ép- 
pen jelen. 


devís 


A /dev könyvtárban található számtalan eszközállomány 
miatt sok operációs rendszer inkább magára a rendszer- 
magra bízza a könyvtár kezelését, hiszen az mindig ponto- 
san tudja, milyen eszközök vannak jelen. Ezt pedig a devfs 
nevű, memória alapú fájlrendszeren keresztül érhetjük el. 
A Linux is rendelkezik ilyen megoldással, amely idővel több 
különféle terjesztésben, például Gentoo Linuxban, vált köz- 
kedveltté. 

A devfs sok ember számára jelent megoldást a közvetlen 
problémákra. Ugyanakkor a Linux-alapú devfs megoldás- 
nak máig van néhány megoldatlan problémája. Legna- 
gyobb hiányossága, hogy nem képes állandó neveken létre- 
hozni eszközcsomópontokat. 


Az udev céljai 

A korábban bemutatott problémák miatt indult el az udev 
projekt. Célja, hogy a felhasználói térben fusson, dinamikus 
/dev könyvtárat hozzon létre, egységes eszközneveket hasz- 
náljon ha szükséges, és felhasználó térbeli API-t biztosítson 
az aktuális rendszereszközök adatainak eléréséhez. Az udev 
és a devfs összehasonlításáról bővebben olvashatunk a há- 
lózati források részben. 

Az első pontot, a felhasználói térben való működést két le- 
hetőség kihasználásával tudja teljesíteni. Egyrészt, az 
/sbin/hotplug eseményeket generál valahányszor egy esz- 
közt eltávolítunk vagy hozzáadunk a rendszerhez, másrészt 
a sysfs bármilyen szükséges információt meg tud adni 

a kiválasztott eszközről. 

A második pontot, azaz a dynami c /dev szolgáltatást, úgy 
éri el, hogy valamennyi /sbin/hotplug eseményt elfogja, 

a sysfsből kikeresi a felvett eszközhöz tartozó major és 
minor számokat, majd az eszközhöz tartozó rendszermag 
névvel létrehozza a /dev állományt. Ha az eszközt eltávoli- 
tottuk, az eszközhöz tartozó /dev bejegyzést már nem túl 
nagy feladat törölni. 

Az udev e két első célját már 2003 áprilisában képes volt 
végrehajtani mégpedig egészen apró, lefordított állapotban 
mindössze 6Kb kód segítségével, annak köszönhetően, 
hogy a hot-plug események elfogására és a sysfs használa- 
tára épülő elképzelés jól megvalósítható és egyszerűen el- 
készíthető volt. A 2003-as szerény kezdeteket követően az 
udev végül valamennyi célját elérte. Felhasználóinak rugal- 
mas szabály-alapú rendszer alapján teszi lehetővé, hogy az 
eszközökhöz állandó neveket rendeljenek. 

Az udev szabályait a /etc/udev/udev.rules állományban talál- 
juk, amely valamennyi olyan eszközt tartalmazza, amelyet 
a felhasználó az alapértelmezett névtől eltérő módon sze- 
retne megadni. 

Nézzünk egy udev.rules állomány példát: 


$ ha a /sbin/scsi id visszatérési értéke 
ff "OEM 08157 az eszközt 

ft disk1-nek nevezzük 

BUS-"scsi", PROGRAM—"/sbin/scsi id", 

55 RESULT-"OEM 08157, NAME-"disk1" 
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f$ USB nyomtatót 1p. color-nak nevezzük 
BUS-"usb", SYSFS serial-"w09090207101241330" , 
5 NAME—"1p. color" 

ft Az adott gyártó és modellszámmal ellátott SCSI 
ft lemezt boot-nak nevezzük 

BUS-"scsi", SYSFS vendor-"IBM" , 

5 SYSFS model-"ST3367", NAME-"boot" 


í A 00:0b.0 azonosítóju PCI hangkártyát dsp-nek 
í nevezzük 
BUS-"pci", ID-"00:0b.0", NAME-"dsp" 


ft A második elosztó harmadik kapujára csatlakozta- 
f$ tott USB egeret 

ft mousel-nek hívjuk 

BUS-"usb", PLACE-"2.3", NAME-"mousel" 


$ A ttyusB1 eszközt mindig pda-nak nevezzük 
tf két további közvetett hivatkozással 
KERNEL-"ttyUSB1", NAME-"pda" , 

5 SYMLINK-"palmtop handheld" 


f USB webkameráinkat és a hozzájuk tartozó 

tt hivatkozásokat 

ft webcamO, webcaml, .. névvel illetjük 
BUS-"7usb", SYSFS model-7xXv37, NAME-"videosn" , 
5 SYMLINK-"webcam9én" 


Az udev szabályok az eszköz tulajdonságai és a kívánt esz- 
köznév közti összerendelést adják meg. Az összerendelés 
megadásához számos kulcsadatot kérdezhetünk le az eszköz- 
ről. Ha az udev.rules állományban nem talál megfelelő bejegy- 
zést, az alapértelmezett rendszermag nevet fogja felhasználni. 
Az udev által megértett kulcsok listáját alább olvashatjuk : 

e BUS: az eszköz busztípusára keres; példák: PCI, USB 
vagy SCSI. 

e "KERNEL: a rendszermag által adott névre keres. 

e ID: a busz eszközszáma; például a PCI busz ID vagy az 
USB eszköz ID. 

e "PLACE: A buszon elfoglalt topológiai helyre keres, mint 
például a fizikai kapu amelyre az USB eszközt csatla- 
koztattuk. 

e SYSFS fájlnév, SYSFS( fájlnév? : segítségével az 
udev bármilyen sysfs eszközjellemzőt kikereshet, pél- 
dául a címkét, gyártót, az USB sorozatszámot vagy 
a SCSI UUID értéket. Egyetlen szabályban maximum öt 
sysfs állományt vizsgálhatunk, melyek mindegyikének 
teljesülnie kell a szabály érvényesüléséhez. 

8 — PROGRAM: az udev külső programot is meghívhat és el- 
lenőrizheti az eredményt. A kulcs a program sikeres 
visszatérése esetén lesz érvényes. A program által 
visszaadott karaktersorozatot aztán tovább vizsgálhat- 
juk a RESULT kulccsal. 

e — RESULT: Az utolsó PROGRAM hívás eredményét teszte- 
li. Ezt a kulcsot a PROGRAM hívás utáni bármelyik kulcs- 
ban használhatjuk. 


A különféle kulcsok után a NAME és az elhagyható SYMLINK 
szavakat adhatjuk meg. A szabály teljesülésekor az udev 
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a NAME részben megadott nevet használja fel az eszköz ne- 
veként, míg a SYMLINK, amennyiben létezik, a szükséges to- 
vábbi közvetett hivatkozásokat határozza meg. Szóköz ka- 
rakterekkel elválasztva egyszerre több hivatkozás is megad- 
ható. A /dev könyvtár egyszerű szerkezetének megtartása 
érdekében a NAME és a SYMLINK állományok könyvtárneve- 
ketis tartalmazhatnak. 


Példa 


Térjünk kicsit vissza a két nyomtatós példánkhoz. Ha 
mindkét nyomtatót egyedi névvel szeretnénk ellátni, a kö- 
vetkező két udev szabályt használhatjuk: 

BUS-"usb", SYSFS serial-"w09090207101241330" , 

5 NAME—"1p. color" 

BUS-7usb", SYSFS serial-"HXOLLO012202323480", 

55 NAME—"1]p. plain" 


A fenti szabályok hatására az udev mindkét nyomtatót meg- 
próbálja megkeresni a sysfs fájlsorozatában, majd a fájl érté- 
kétől függően Ip. color vagy Ip. plain névvel látja el az esz- 
közt. Ezáltal, függetlenül attól, melyiket csatlakoztattuk előbb 
mindkét nyomtató ugyanazt az állandó nevet kapja. Az sem 
okoz zavart, ha más USB nyomtatót is csatlakoztatunk. 


Különleges udev szabályok 

Az udev alatt a udev.rules állomány NAME, SYMLINK és PROG- 

RAM mezőinek megadásához különféle printf-szerű szö- 

veghelyettesítést is használhatunk. A használható mezők 

a következők: 

e  96n: az eszköz rendszermag száma; például az sda3 esz- 
köz rendszermag száma 3. 


e 36k: az eszköz rendszermag-neve. 
e XM: az eszköz rendszermag szerinti major száma. 
e — 2m: az eszköz rendszermag szerinti minor száma. 


e  96b: az eszköz sín azonosítója. 

e  96c:a PROGRAM által visszaadott szöveg. A szövegből 
kiemelhetjük valamelyik szót, ha a módosítót számmal 
egészítjük ki. Ez a mező magától értetődő módon 
a PROGRAM mezőben nem működik. 

e 996: maga a 9 karakter. 


Ezen kívül bizonyos kulcsokkal héjprogramszerű mintake- 

resést végezhetünk. A keresőminták a következők: 

e "7: nulla, egy vagy több karaktert keres. 

e  ?: egy darab tetszőleges karakter, amely nem lehet 
nemlétező (nulla hosszú). 

e  [ ]:a zárójelek közt felsorolt bármelyik karakter; példá- 
ul a ttyISR] minta egyaránt megtalálná a ttysS és 
a ttyR szöveget. A keresés a - jel használatával támo- 
gatja a tartományokat is. Például ha valamilyen számot 
keresünk, a [0-9] mintát használjuk. Amennyiben a [ 
jelet a ! karakter követi, csak az itt fel nem sorolt karak- 
ter lesz érvényes találat. 


A fent bemutatott szöveghelyettesítési és szövegkeresési 
módszerek alkalmazása, valamint az, hogy az udev tetsző- 
leges programot képes futtatni majd eredményét felhasz- 
nálni, rendkívül rugalmas eszközzé teszik az eszköznév 
kiosztás terén. E hatékonyság érzékeltetésére nézzük meg 
a következő szabályt: 








KERNEL—"[hs]d[a-z]", PROGRAM-"name cdrom.pil 96M 98m" , 
59 NAME—"961c", SYMLINK-"cdrom" 


A fenti szabály bármely blokkos eszközt megtalál, majd az 
eszköz major és minor számával meghívja a name. cdrom.p1 
Perl parancsfájlt. Ha a program sikeresen lefutott, az udev 

a kimenet első szavát használja fel eszköznévként, majd lét- 
rehozza a cdrom közvetett hivatkozást. 

A name. cdrom.p1 parancsfájlt megtaláljuk az udev terjesztés- 
ben. A parancsfájl feladat a következő: megállapítja, hogy az 
eszköz CD-ROM eszköz-e. Amennyiben igen, a Free CDDB 
adatbázisra küldött lekérdezéssel ellenőrzi, hogy az eszköz- 
ben használt CD-ROM létezik-e az adatbázisban. Amennyi- 
ben létezik, ennek alapján nevezi el a CD-t. Például a saját 
/dev könyvtáram a szabály alkalmazását követően a követke- 
zőképpen néz ki: 


$ 1s -1 /dev/S" /dev/cdrom 

1 root root 22, 64 Feb 15 08:26 
5 /dev/Samiam-Astray 
Trwxrwxrwx 1 root root 
5 /dev/cdrom -5 
/dev/Samiam-Astray 


8 Feb 15 08:26 


Megfigyelhettük hogyan képes az udev internetes adat- 
bázisok alapján elnevezni az eszközünket. 

Igen, ez valóban kicsit őrült névhasználati szabály, 

de jól példázza mire képes és milyen rugalmas tud len- 
ni az udev. 





Köszönetnyilvánítás 

A szerző szeretne köszönetet mondani Daniel Stekloff-nak 
az IBM munkatársának, aki segített formába önteni az udev 
rendszert. Az ő kitartása nélkül az udev nem jöhetett volna 
létre. Valamint Kay Sievers-nek, aki az udev különleges ké- 
pességeinek kialakításában játszott fontos szerepet, különös 
tekintettel a karaktersorozat módosítókra és mintakeresésre, 
melyek nélkülözhetetlenek az udev éles használatához. Segít- 
sége nélkül az udev közel sem lenne olyan hatékony és hasz- 
nálható mint amilyen manapság. Pat Mochel sysfs és meg- 
hajtó modell-magja nélkül az udev szintén nem lett volna 
megvalósítható. A szerző lekötelezve érzi magát, hogy magá- 
ra vállalta amit a legtöbben megvalósíthatatlannak tartottak 
és, hogy lehetővé tette másoknak az egységes keretrendsze- 
rére való építkezést, lehetővé téve minden felhasználónak 

a hogy átlássák a rendszermagban használt , belőtt pók szót- 
te hálót" ( Web woven by a spider on drugs", a rendszer- 
mag-meghajtókat nyilvántartó adatszerkezet neve — a ford.). 
A cikk az 2002-es Ottawa-i Linux Symposium udev témájú 
publikációja nyomán készült (lásd a forrásokat). 


Linux Journal 2004. június, 122. szám 


Greg Kroah-Hartman jelenleg több különféle 
meghajtó alrendszer Linux rendszermag gaz- 
dája. Az IBM-nél dolgozik, ahol Linux rend- 
szermaggal kapcsolatos dolgokkal foglalkozik 
és a gregokroah.com címen érhető el. 




















www.linuxvilag.hu 


39 


2004. szeptember 


0 Kiskapu Kft. Minden jog fenntartva 





Szaktekintély 


0 Kiskapu Kft. Minden jog fenntartva 





Osztott biztonsági rendszer Linux-telepeken 


A cikkből megtudhatjuk, hogy milyen rendszermag-szintű eljárást használ 
az osztott biztonsági modul (DSM) a biztonsági információk IP-üzenetekbe 


való átlátszó-ágyazásához. 


jelen cikk az osztott biztonsági háttérről 
A (Distributed Security Infrastructure, DSI) és az 

osztott biztonsági modulról (Distributed Security 
Module, DSM) korábban megjelent cikkek folytatása (lásd 
a Linuxvilág 2002 novemberi, 22. számában megjelent 
Az osztott linuxos biztonsági modell és a DSI: biztonságos 
Linux a távközlésben című cikkeket, valamint az eredeti 
angol nyelvű cikkeket a Linux Journal honlapján: , Linux 
Distributed Security Module" , LJ, 2002 októberi szám, 
5 http:/www.linuxjournal.com/article/6215, illetve a DSI: 
a New Architecture for Secure Carrier-Class Linux Clusters, 
5 http:/www.linuxjournal.com/article/6053). Jelen cikkben 
arra fókuszálunk, hogy egy osztott környezetben hogyan 
használjunk a DSM-ben IP beállításokat biztonsági informá- 
ciók küldésére a folyamatszintű biztonság megvalósításá- 
hoz. Kitérünk a hálózati átmeneti tár kezelésére, a kapcsok 
rendszermagjbeli létrehozására, az IP beállításokra és az IP 
fejrész módosítására. Ezt követően a DSM hálózati kapcsait 
tárgyaljuk és bemutatjuk néhány előzetes teljesítményteszt 
eredményét. 


A DSI projekt 


Az Ericsson Research nyílt rendszerekkel foglalkozó labora- 
tóriuma a nyílt forrású DSI projektet azzal a céllal indította 
útjára, hogy egy olyan programalapú valós idejű kommu- 
nikációs rendszert fejlesszen ki, amely carrier-grade osztá- 
lyú, Linux-alapú távközlési telepeken futtatható. Ezeknek 
a telepeknek bármilyen gép- vagy programhibától függet- 
lenül folyamatos üzemmódban kell működniük, és lehető- 
vé kell tenniük a karbantartók számára, hogy a programot, 
a berendezéseket, a rendszermagot vagy az alkalmazásokat 
működés közben frissítsék. Mindezt úgy, hogy az a kínált 
szolgáltatásokat ne befolyásolja, és ne legyen semmiféle 
leállás sem. 

A DSI-t eredetileg az olyan carrier-grade jellemzők meg- 
valósítására tervezték, mint a megbízhatóság, méretezhe- 
tőség, nagyfokú hozzáférhetőség és nagy teljesítmény. 
Ezeken felül számos más fontos jellemzővel is rendelkezik. 
Ilyen az egységes keretrendszer, a folyamatszintű megkö- 
zelítés, és az, hogy támogatja az időosztásos biztonsági 
szabályokat, és a menet közben frissíthető biztonsági 
rendet egyaránt. A DSI fontos jellemzője a folyamatszintű 
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1. kép A hálózati csomag útja a rendszermagban 




















2. kép Biztonsági beállítások az IP-fejrészben 


hozzáférés-ellenőrzés. A jelenleg megvalósított biztonsági 
eljárások a felhasználói jogosultságokon alapulnak, és nem 
támogatják azokat a hitelesítéseket, amelyek ugyanazon 
felhasználóhoz tartozó két folyamat kölcsönhatására vo- 
natkoznak akár távoli feldolgozóegységek által létrehozott 
folyamatok esetén. Távközlési alkalmazások esetén csak 
kevés felhasználó futtatja megszakítás nélkül hosszabb ide- 
ig ugyanazt az alkalmazást. A fenti megközelítés használa- 
ta a különböző hálózati csomópontokon indított folyama- 
tok mindegyikének ugyanazokat a biztonsági jogokat adja, 
amely ahhoz vezet, hogy a megosztott rendszeren számos 
művelet biztonsági ellenőrzés nélkül futhat. Az említett 











1. lista sock sendmsg() 


sock sendmsg 
(struck socket "sock, struct msghdr "msg, int 
s size) 
j 
int err; 
struct scm cookie scm; 


el 
security ops-ssocket ops-ssendmsg(sock, 
msg, size); 
ifC(err) 
return(err); 


2. lista dsi socket sendmsg() 


int dsi socket sendmsg(struct socket "sock, 
S struct msghdr "msg, int 
5 size) 


inode security t "isec; 

struck sock sk; 

SÉFUCGT ip-options "opt — NULL 

int optlen - NSID BASE LEN 4 NSID SSID LEN - 
NSID NODEID LEN; //8 46 46 

unsigned char optptrloptlen]; 


sk - sock-ssk; 

opt - sk-sprotinfo.af inet.opt; 

dsi options fill (isec, optptr, optlen); 
dsi ip options get(gopt, optptr, optlen); 
opt - xchg(£sk-sprotinfo.af inet.opt, opt); 


biztonsági rendszer alapegysége a felhasználó. A vivő- 
szintű (carrier-class) alkalmazások esetén ez a felosztás 
nem megfelelő, finomabb megközelítésre van szükség, 
ezért támogatja a DSI is az egyedi folyamatot, mint 

a felosztás alapegységét. 


Az osztott biztonsági modul (DSM) 

A DSM a DSI központi összetevője, amely biztosítja a Linux 
telepen belül a kötelező érvényű hozzáférés-ellenőrzés 
megvalósítását. A DSM felelős a hozzáférés-ellenőrzés vég- 
rehajtásáért, és biztosítja, hogy a telep csomópontjain átha- 
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ladó IP-üzenetek el legyenek látva a küldő csomópont és 
folyamat biztonsági jellemzőit tartalmazó címkével. A DSM 
az LSM-kapcsokat használó Linux modulként került meg- 
valósításra. A fejlesztés a 2.4.17-es Linux rendszermag hasz- 
nálatával kezdődött egy megfelelő LSM-rendszermagfolt al- 
kalmazásával. Ez a megvalósítás az IP-fej módosítását leíró 
CIPSO és FIPS 188 szabványokra épül. 

A DSM megvalósításának fontos eleme az osztott jelleg. 
Egy telepen belüli csomópontról kiinduló hozzáférés-ellen- 
őrzés vonatkozhat egy olyan erőforrásra, amely egy másik 
csomóponton helyezkedik el, ezért szükség van arra, hogy 
létezzen a telepen belüli csomópontok között a biztonsági 
információk átvitelének a lehetősége. A DSM osztott jellege 
biztosítja, hogy az erőforrásokhoz való hozzáférés biztonsá- 
gi szempontból helyfüggetlen legyen. 


A hálózati átmeneti tár kezelése 

Röviden összefoglaljuk a hálózati átmeneti tár kezelését an- 
nak érdekében, hogy jobban megérthessük, hogyan ágya- 
zódik a biztonsági információ a hálózati csomagba. Leírjuk 
azt is, hogy a rendszermag hogyan kezeli a hálózati tárat 

a felhasználói rétegtől a hardverrétegig és vissza. 

Az 1. kép a hálózati csomag útját mutatja a rendszermag- 
ban. A csomagkezelés két esete a bejövő, illetve kimenő cso- 
magok kezelése. A kimenő csomagok kezelése az alkalma- 
zói rétegtől kezdődően a következőképpen alakul: az alkal- 
mazás előkészíti az adatot a hálózaton keresztül történő to- 
vábbításra; az alkalmazás a csomag küldésére vonatkozó 
rendszerhívást küld a rendszermag felé; a csomag sk buff 
szerkezetben áthalad a rendszermag szűrő és útválasztó 
függvényein; végül a csomag a hálózati meghajtóhoz kerül, 
amely azt a hálózati kártyára (DMA) továbbítja. 

A bejövő hálózati csomag útja a hálózati kártyától kezdődő- 
en oly módon indul, hogy a kártya begyűjti a saját vagy 
csoportos (broadcast) címével megcímzett csomagot; ezután 
beolvassa a hálózati memóriába, és egy megszakítást hoz 
létre. A hardveres megszakítás által kiváltott és a hálózati 
kártya meghajtóprogramjának részeként a rendszermagban 
elhelyezkedő megszakítás-kiszolgáló rutin lefoglal egy 

sk buff területet, majd a hálózati kártya memóriájából 
(DMA) ebbe az átmeneti tárba mozgatja át az adatokat. 

Ezt követően a csomag a felsőbb rétegbeli feldolgozás cél- 
jából a processzor várakozási sorába kerül, a feldolgozás 
pedig akkor folytatódik, amikor a megszakítás engedélye- 
zetté válik. Végül a csomagok keresztülhaladnak a szűrő- 
kön és útválasztó függvényeken, és az alkalmazói réteg felé 
továbbítódnak. 

Most, hogy már ismerjük az általános módszert, amivel 

a Linux rendszermag kezeli a hálózati átmeneti tárat, be- 
mutatjuk, hogy mindezt hogyan használhatjuk fel a rend- 
szermag biztonságának növelésére. 

Megvizsgáljuk az IP útválasztó függvényekhez létreho- 
zott kapcsokat, amelyek lehetővé teszik az IP-csomagok 
befolyásolását és növelik az IP-üzenetek biztonsági lehe- 
tőségeit. 


Hálózati biztonsági kapcsok létrehozása 

A biztonsági modul képes befolyásolni a biztonsági kapcsok 
megvalósításán alapuló útvonal kiválasztási döntéseket. 
Mivel az útválasztó kapcsok a rendszermagba érkező és 
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3. lista ip options compile () 


úm 

ipcoptions compile (struct ip. options "opt, 
SStruct:skébüft :skb) 

1 

unsigned char "pp ptr; 

unsigned char "optptr; 


Case sROPJTEETÉSOS 


if(security ops-sip. ops-sdecode. options (skb, 
ssoptptr, €§pp.ptr) 
goto error; 
break; 


onnan kimenő csomagok esetén normál rendszermag-függ- 
vényként futnak, ezek programozásánál fel kell idéznünk 
néhány dolgot. 

A függvényt regisztráló modulnak rögzítenie kell a függ- 
vény kapcson belüli prioritását. A hálózati szűrő kapcsok 
a rendszermag-kódjából a prioritásuknak megfelelő sor- 
rendben kerülnek meghívásra. 

A felhasználói függvények szabadon módosíthatják az IP- 
csomagokat, és az alábbiak közül kell egy értéket visszaad- 
niuk a hálózati kód számára, hogy az eldönthesse, mi a te- 
endő a csomaggal: 


1. NF. ACCEPT: nincs semmi tennivaló, a csomagot átengedi 
a hálózati vermen. 

NF. DROP: a csomag eldobása, nincs további feldolgozás. 
NF. STOLEN: a csomag átvéve, nincs további feldolgozás. 
NF. OUEUE: a csomag sorbaállítása felhasználói kezelésre. 
NF. REPEAT: a kapocs ismételt meghívása. 


S s 59 Bo 


Ez a kód megmutatja, hogy mi történik a csomaggal, 
mielőtt a rendszerbe vagy onnan kiküldésre kerül. 

Azt viszont még mindig nem tudjuk, hogy milyen infor- 
mációkat vagy beállításokat adhatunk a csomaghoz, és 
hogyan tehetjük azt meg. További kérdés, hogy vajon 
ezek a változtatások együttműködnek-e a jelenlegi 
megvalósítással. 


IP-heállítások 

Az internet-protokoll (IP) egy kevésbé ismert tulajdonsága, 
hogy egy IP-csomag változó hosszúságú (maximálisan 

40 bájt) többletinformációt is tartalmazhat, amely a szabvá- 
nyos 20 bájtos fejrészt követi. Ez a kiegészítés az úgyneve- 
zett opcionális terület, amelynek egy része biztonsági infor- 
mációk tárolására van fenntartva. 

Jelenleg az Internet Protokoll két biztonsági beállítást tartal- 
maz. Ezek közül az egyik a DoD Basic Security Option (alap 
biztonsági beállítás, 130-as beállítástípus), amely lehetővé 
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4. lista sock gueue rev skb () 


ait 

sock gueue rcv skb (struct sock "sk, 
S-StrÜGtEskébütteeskbd 

í 


ünesekrz0; 


err-security ops-ssocket ops-ssock rcv skb 
Sz ÜSkeskbdis 


if(err) 
return (err); 


teszi, hogy az IP-adatcsomagokat a titkosítás foka szerinti 
címkével lássuk el. Ez a beállítás 16 titkosítási fokozatot kü- 
lönböztet meg, amelyek különböző számú megszorítást tar- 
talmaznak a csomag kezelésére vonatkozóan. További biz- 
tonsági információk kezelését, mint amilyen a biztonsági 
osztály és szakasz megkülönböztetése, a második biztonsági 
beállítás teszi lehetővé, amelyre DoOD Extended Security 
Option (ESO, kiterjesztett biztonsági beállítás, 133-as beállí- 
tástípus) néven hivatkozik a szakirodalom. E két beállítás 
adatterületének értékeit az Információs Rendszerek Védel- 
mi Irodája (Defense Information Systems Agency) hivatott 
nyilvántartani. 

A számítógép forgalmazók ma már olyan kereskedelmi 
operációs rendszereket kínálnak, amelyek kötelező hozzá- 
férés-ellenőrzéssel és többszintű biztonsági beállításokkal 
rendelkeznek, s ezek a rendszerek már nem kizárólag 

a védelmi vagy hírszerzési szervezetek számára készül- 
nek, hanem olyan, nyilvánosan hozzáférhető kereskedel- 
mi rendszereknek, amelyeket az állami és civil szféra is 
elterjedten használ. 

A kisszámú ESO formátumkód nem támogatja a kereske- 
delmi biztonsági beállítások összes lehetséges alkalmazási 
módját. A BSO és ESO tervezésekor csak az Egyesült Álla- 
mok Védelmi Minisztériumának támogatása volt a cél. 

A különböző egyéb biztonsági módok támogatására 

a CIPSO (Commercial IP Security Option, kereskedelmi IP 
biztonsági beállítás) került kidolgozásra. Az internetes ter- 
vezet biztosítja a kötelező hozzáférés ellenőrzés (mandatory 
access control, MAC) biztonsági rendjéhez szükséges formá- 
tumot és eljárásokat. 

A mi megvalósításunkban az adatcsomagok címkézésé- 

re használt IP-beállítások a FIPS 188 szabványon és a ke- 
reskedelmi IP biztonsági beállításon (CIPSO) alapulnak. 

Az általunk kifejlesztett rendszerben az IP fejrészt ezen 
szabványok szerint változtatjuk meg, hogy alkalmassá 
tegyük a biztonsági információk hozzáadására és háló- 
zaton való küldésére. 


A DSM IP- sai 

Az IP-beállítások segítségével továbbítandó két biztonsági 

információ a biztonsági azonosító (Security ID, SID) és 

a biztonsági csomópont-azonosító (Security Node ID, NID). 

A DSM úgy módosít minden egyes IP-csomagot, hogy IP- 

beállításként ellátja azokat ezekkel a biztonsági informáci- 

ókkal. A 2. képen látható ennek a módosított IP fejrésznek 

a felépítése. 

A fejrész beállításainak listája a következő: 

e  CIPSO: 1 bájt, 134-es értékkel. 

e — Hossz: 1 bájt, amelynek értéke a teljes hossz, beleért- 
ve a típus és hossz mezőket is. A jelenlegi IP-fejrész 
40 bájtos korlátja miatt ez az érték nem haladhatja 
meg a 40-et. 

e Az értelmezési tartomány (DOI) azonosítója: előjel 
nélküli 32 bites egész. A 0 foglalt érték és nem jelenhet 
meg egy CIPSO beállítás DOI-azonosítójaként sem. 

A megvalósításoknak el kell fogadniuk, hogy a DOI- 
azonosítót nem köti semmilyen különleges bájtszintű 
korlátozás. 

e A CIPSO értelmezési tartomány mező vagy a FIPS 188 
szerinti biztonsági jelkészlet neve: ez 10001000 hexadeci- 
mális értékre van beállítva, ami egy önkényes érték, mi- 
vel jelenleg erre a területre nincs érvényes korlátozó 
szabály. 

e Szabad formátum-jel: egy bájt, amely azt jelzi, hogy az 
ezt követő mezők olyan új mezők, amelyeket a szab- 
vány nem határoz meg (vagyis tetszőlegesek). Értéke 7. 

e — Hossz: 1 bájt, a címkék teljes hosszát jelöli. 
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e . Címkék (SID, NID): A CIPSO címkecsoportokat használ 
az IP-csomagban tárolt adatokra vonatkozó biztonsági 
információk tárolására. Minden címke egy címketípus 
azonosítóval kezdődik, a címke hosszával folytatódik, 
majd végül ezt követi a tényleges biztonsági információ. 

e SID címke: címkeazonosító: 1 bájt (értéke 3), címke- 
hossz: 1 bájt (értéke 6), címkeadat: a sid 32 bites értéke. 

e  NID címke: címkeazonosító: 1 bájt (értéke 6), címke- 
hossz: 1 bájt (értéke 6), címkeadat: a nid 32 bites értéke. 

e Az általunk használt IP-beállítás a CIPSO. Ezeket a me- 
zőket a szabvány nem határozza meg, így használható- 
ak az általunk definiált módon. 

e A DOI és a FIPS 188 szabvány szerint a következő me- 
zők új mezők, amelyeket a szabvány nem határoz meg, 
ezért szabadon felhasználhatóak. 


DSM hálózati kapcsok 

A DSM-ben az LSM biztonsági kapcsokat használtuk fel az 
IP üzenetek biztonsági címkékkel történő ellátására. A kö- 
vetkezőkben ezt egy példán keresztül fogjuk szemléltetni, 
amelyben a program a hálózaton keresztül olyan csomagot 
küld, amelynek a foglalatát módosította. A program hasz- 
nálja az eljáráskönyvtár néhány függvényhívását. Egy pon- 
ton egy rendszerhívás jön létre, amely az üzenetet a Linux 
rendszermagnak továbbítja. A rendszermag foglalat-megva- 
lósításának belépési pontja a sys socketcal1O függvény, 
amely a net/socket.c fájlban található. A hívásláncban 

a net/socket.c fájlban lévő sock sendmsgO függvény (1. lista) 
futtatása történik. 





Szavazz a CD-mellékletről! 


Tavasszal , Szerkeszd te is a Linuxvilágot!" 

felhívással egy on-line kérdőív kitöltésére kértük 
olvasóinkat honlapunkon, melynek értékelése a júliusi 
számban jelent meg (a bővebb változat honlapunkon is 
elérhető http://www.linuxvilag.hu/hir/1022/711.html]). 


Az eredmény alapján készítettünk egy tervezetet a CD- 


melléketre vonatkozó változtatásokra. Ennek megvaló- 


sításáról a Ti szavazataitok fognak dönteni, ezért kérünk 
mindenkit, hogy válaszoljon 3 kérdésre ezen az oldalon: 


http://vww.linuxvilag.hu/kerdoiv. cd 
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A függvény első tevékenységeinek egyike a biztonsági ka- 
pocs futtatása (security ops-2socket ops-:sendmsg(...)). 

A kapocs a DSM foglalat-kapocsban ér véget, amely ai IP 
csomagot módosítja, mint az a 2. listán látható. 

A dsi options fill függvény elindítja a biztonsági infor- 
mációt az átmeneti tár felé, ahogy azt az előző részben le- 
írtuk. Az ezt követő függvények végrehajtása során kerül 
ez az információ az IP-üzenet beállítási részében rögzítés- 
re. A SID a foglalat biztonsági azonosítójából származik, 

a NID pedig az egész csomópontban érvényes érték, va- 
gyis nincs szükség arra, hogy a függvénynek paraméter- 
ként átadjuk. 

Ezt követően a biztonsági információkat már tartalmazó 
módosított csomag a normál feldolgozó eljárásnak megfe- 
lelően kerül továbbításra a rendszermag felé, majd a háló- 
zatra. A fogadó oldalon a bejövő üzenetek az sk buff 
szerkezetnek megfelelően tárolódik és különböző függvé- 
nyek és kapcsok sorozata által kerül elő-feldolgozásra. 

Az egyik ilyen függvény az ip. options compile (3. lista) 
a /net/ipv4/ip options.c fájlban, amely a beállításokat 
dolgozza fel. 

A CIPSO esetén a decode options biztonsági kapocs kerül 
meghívásra. Ez után következik a DSM dsi. decode options 
kapocs, amelyben a bejövő csomag biztonsági paraméterei 
(SID, NID) kerülnek kiolvasásra és tárolódnak egy az sk buff 
formátumhoz kapcsolódó biztonsági formátumban. A biz- 
tonsági információkkal feltöltött sk buff tárolók a bejövő 
foglalatsorhoz csatlakoznak, és itt várjuk, hogy a fogadó 
program kiolvassa őket. 

A kiolvasás érdekében a program egy sys socketcall] O 
rendszerhívást bocsát ki, ugyanúgy, ahogy a küldött cso- 
mag esetén is tette. A hívás ismételten átmegy a DSM biz- 
tonsági kapcson, ahol a fogadó foglalat biztonsági azonosító 
érvényesítésre kerül a bejövő csomag sk. buff biztonsági 
tartalmával. Ha a foglalat a megadott biztonsági azonosító- 
val nem fogadhatja a csomagokat, akkor azok elvesznek. 

A 4. listán látható az include/net/sock.h fájlban lévő rendszer- 
mag-függvény. 

Ebben láthatjuk, hogy a sock rcv. skb biztonsági kapocs 
kerül meghívásra, amit a dsi. sock rcv. skb DSM-függvény 
vált fel a DSM betöltődésekor. Ebben a függvényben törté- 
nik a biztonsági érvényesítés. A példakódból láthatjuk, 
hogy milyen műveletekre van szükség a biztonsági címkék 
kezeléséhez. 


Teljesítményvizsgálatok 

Számos sebességtesztet végeztük arra vonatkozóan, hogy 
az IP-fejrész kibővítése a beállításainkkal befolyásolja-e az 
átfogó teljesítményt, és ha igen, milyen mértékben. Az 
egyik tesztben egy UDP-csomagot küldtünk át a telep cso- 
mópontjai között és mértük a csomag átviteléhez szükséges 
idő növekedését, ami a küldő oldalon a biztonsági beállítá- 
sok módosításából, a fogadó oldalon pedig ezek kinyerésé- 
ből adódhatott. 

A megvalósításunkon alapuló biztonsági információk hoz- 
záadása okozta többletmunka átlagos értéke 3096 volt. En- 
nek nagy részét (mintegy 25970-ot) az IP-csomag IP- 
beállításain végzett módosítása tette ki, a maradék többlet- 
munka (körülbelül 570) pedig a Linux rendszermag bizton- 
sági kapocs-rendszeréből származik. Látható, hogy a több- 
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let nagy rész az IP-csomag beállításainak a módosításából 
származik és csak kisebb rész írható a biztonsági kapcsok 
rendszerének számlájára. 

A jövőbeli erőfeszítéseink arra fognak irányulni, hogy nö- 
veljük IP-módosító algoritmusunk hatékonyságát, miköz- 
ben továbbra is az IP-beállításokat tekintjük a biztonsági in- 
formációk átviteli eszközének. 


Osszegzés 

Az IP-beállítások megváltoztatásával képesek voltunk arra, 
hogy a DSM segítségével biztonsági információkat továbbít- 
sunk a telep csomópontjai felé. Az IP-csomagok módosítá- 
sának optimalizálásával már első próbálkozásra is jelentős 
teljesítnénynövekedést értünk el: a 3075-os teljesítmény- 
csökkenést sikerült 1490-ra leszorítani. Ezek az eredmények 
igen ígéretesek, több olyan lehetőséget is látunk a további 
tökéletesítésre, amellyel még kisebb többletmunkával érhet- 
jük el a célunkat. Mindenesetre az eredmények jól mutatják 
azokat a kihívásokat, amelyekkel egy hatékony osztott biz- 
tonsági rendszer fejlesztése során szembe kell néznünk. 
Reméljük, hogy minél többen próbálják majd ki az általunk 
kifejlesztett DSI és DSM technológiát és megosztják velünk 
a tapasztalataikat. 
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A DSI és DSM honlapja: 

2 www.linux.ericsson.ca/dsi 

A FIPS 188 szabvány: 

2 csre.nist.gov/publications/fips/fips188.html 
Cikkek a Linux csomagszűrőjéről: 
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2 www.linuxjournal.com/article/5617 

Az LSM: 5 Ism.immunix.org 

Hálózati átmeneti tárak: 

2 www.linuxjournal.com/article/1312 

Az Open System Lab oldala: 5 www.linux.ericsson.ca 
A SE Linux honlapja: 5 www.nsa.gov/selinux 
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Intelligens útválasztás: szórakozás és anyagi haszon 


Biztosítsuk magunknak a szükséges sávszélességet anélkül, hogy a hónap végén 


hanyatt esnénk a számlától. 


Sangoma PCI felületű WAN-kártyákat gyártó cég. 
A Bemutató és biztonsági tartalék céljából két külön- 

álló szélessávú Internet-kapcsolattal rendelke- 
zünk: egy T1-es Frame Relay kapcsolattal, amely a PCI-os 
55148 T1/E1I modemünket használja, és egy PPPoE proto- 
kollos ATM-re épülő ADSL kapcsolattal, amely a PCI felüle- 
tű 5518 ADSL modemünket veszi igénybe. Az ADSL- 
vonalat a faxgépünkkel osztottuk meg, amely az egyetlen 
olyan telefonvonal, ami nem kapcsolódik a PBX-ünkre (házi 
telefonközpont). A vonalakat két külön szolgáltató biztosít- 
ja. Az ADSL-t és a faxkészülék telefonvonala a Bell Canada 
Sympatico szolgáltatása, a TI Frame Relay kapcsolatot pe- 
dig az MCI-tól vesszük igénybe. 


A sávszélesség és annak költségei 

A telepített TI és ADSL-kapcsolat együttese valóban 
megbízható kapcsolatot biztosít, viszont a kapott sávszé- 
lesség több, mint amire szükségünk van. 

A Sangoma honlapjának az atlantai Earthlink ad helyet, 
így a világhálóval kapcsolatos igényeink nagyjából meg- 
egyeznek bármilyen más cég igényeivel. Elsősorban elekt- 
ronikus levelezéssel és Web-eléréssel kapcsolatosak, ami 
kiegészül némi FTP-forgalommal. Utóbbi főleg a web- 
oldalunkon lévő FTP-kiszolgálóra feltöltött anyagokkal 
kapcsolatos. Meglennénk állandó IP-címek nélkül is, de 
azért hasznosnak találjuk, hogy a T1 kapcsolatunk rendel- 
kezik egy rögzített IP-címtartományal. 

Az összes Internetes kiszolgálónkon Linux fut. Bár támo- 
gatjuk a Windows, FreeBSD, Solaris és még más népszerű 
operációs rendszereket is, a legfontosabb a Linux, és csak 
ez az operációs rendszer rendelkezik a számunkra szüksé- 
ges gazdag forgalomkezelő eszközkészlettel. Az 1. képen 
látható a leírt elrendezés felépítése. 

Az ADSL-vonal nem kerül sokba, különösen azzal az en- 
gedménnyel együtt, amit annak fejében kaptunk, hogy sa- 
ját ADSL-modemet használunk, ez normális körülmények 
közt a szolgáltatás részét képezi. A T1-vonal költségei vi- 
szont magasak, ha az Egyesült Államokhoz hasonlítjuk: 
egy korlátlan T1 Internetes kapcsolat ára elérheti a havi 
1.900 kanadai dollárt (1.450 amerikai dollár). 

A Sangoma az Internetes hozzáférését a költségek vala- 
melyes ellensúlyozása érdekében tovább értékesíti az 
épület két másik bérlőjének. A kapcsolatunkat megosztó 
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1. kép Takarékossági és üzembiztossági megfontolások alapján 
a kiszolgáló mind TI, mind ADSL kapcsolattal rendelkezik 


bérlők Webhely- és VPN szolgáltatásokat nyújtanak, így 
nekik rögzített IP-címekre és nagy kimenő sávszélességre 
van szükségük, emiatt a T1-vonal megosztásában érdekel- 
tek. A T1-vonal belső és nyilvános szegmenseit a 2. kép 
mutatja. 

A Sangoma két Linuxos gépe könnyedén összeolvasztható 
eggyé. Az így létrejövő útválasztó rendelkezne egy újabb 
hálózati csatolóval az A és B ügyfél nyilvános hálózati szeg- 
menseinek támogatására, a Sangoma tűzfala pedig 

a Sangoma belső hálózati szegmense és az összes többi nyil- 
vános szegmens közt helyezkedne el (magában foglalná 

a Frame Relay T1 kapcsolatot, az ADSL kapcsolatot és 

a nyilvános Ethernet kapcsolatot). 

Az ügyfelektől kapott anyagi hozzájárulás nem elegendő 
arra, hogy kifizessük belőle a T1 kapcsolat teljes kanadai 
árát. A megoldást az jelentette, hogy a T1 használatán ala- 
puló szolgáltatást választottunk. Ez az úgynevezett 
burstable T1 szolgáltatás, amely a teljes sávszélességű T1- 
nek csak körülbelül a felébe kerül. A T1 korlátlanul használ- 
ható a teljesen kétirányú 1,536 Mbps sávszélességig. 

A számlázás a használt sávszélesség-érték 95 százalékos ér- 
tékén alapul. 

A forgalmat ötpercenként mintavételezik és kiszámolják az 
öt perc átlagosan használt sávszélességét. A hónap végén 
ezeket az ötperces értékeket átviteli sebesség alapján csök- 
kenő sorrendbe rendezik. A legmagasabb 595-ot figyelmen 
kívül hagyják, a fizetendő díj alapja pedig a következő leg- 
nagyobb sávszélesség-érték. Az átvitel határa esetünkben 
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Az egy hónap alatti sávszélesség megoszlás a T1 vonalon 





2. kép Az épület két bérlője vesz igénybe 
Internet-hozzáférést a Sangoma-tól 


128 kbps. Ha a 95. százalékértékünk meghaladja ezt a 128 
Kbps értéket, a díj legalább 300 dollárral megemelkedik. 

Az előfizetők nehezen értik meg ezt a bonyolult számlázási 
rendszert. Az ügyfél számára jó üzletnek tűnik, de a kezelé- 
se bonyolult, és nehéz mérni az értékeket. 

számlázás alapjaként szolgáló értéket az 590-os szint- 

nél mérik, ahol a felhasználás görbéjének változása 

a maximum körül van. Sok felhasználó fizet olyan szám- 
lákat, amelyek magas értékét csak egy-két olyan ötper- 

ces szakasz okozza, amelyek kilógnak a havi több mint 
8500 mérési értékből. 

Hacsak nem egyenletesen alacsony a forgalmunk, könnyen 
azt tapasztalhatjuk, hogy a pótdíjak ilyen rendszere mellett 
ráfázunk és kifizetjük a teljes T1 árát, holott az átlagos átvi- 
telünk jóval 128kbps alatt volt. 

A rendszer legfőbb előnye, hogy a legmagasabb sávszéles- 
ségű 590 felhasználása minden hónapban , ingyenes". 

Ez havonta körülbelül 36 tetszőleges sávszélességű órát 
jelent mindenféle büntetés nélkül, vagyis egy hónapban 
majdnem egy hét munkaórátit tölthetjük a teljes sávszéles- 
ség kihasználása mellett. A 3. képen látható az ideális forga- 
lommegosztás, amely az általunk választott fizetési rend- 
szer mellett a legkevesebb díj fizetésével elérhető legna- 
gyobb átvitelt tenné lehetővé. A forgalomirányító logika 
lényegében 128 kbps sebességre korlátozná a sávszélessé- 
get, miután az adott hónapra eső első 36 óra korlátlan sáv- 
szélességét felhasználtuk. 

Nos, hogyan lehetne megszerezni a csalit anélkül, hogy vele 
együtt a horgot is bekapnánk? A megfelelő policy routingot 
(intelligens útválasztást), IP-fiókkezelést és forgalom ellenőr- 
zést megvalósító parancsfájlok és démonok együttesével in- 
telligensen szabályozhatjuk a hálózati forgalmat, így a saját 
és társfelhasználóink számára elérhetővé válik a legnagyobb 
teljesítmény a legalacsonyabb díj mellett. 


Intelligens útválasztás IP-táblák és az iproute2 
segítségével 

Az első lépés, hogy minden olyan forgalmat leveszünk 

a T1-ről, amely átterhelhető az ADSL-re anélkül, hogy ezzel 
a szolgáltatás színvonala csökkenne. Az ADSL-vonalunk 
legnagyobb letöltési sebessége 1.728 kbps, a feltöltésé pedig 
800 kbps. A T1 névleges sebessége 1.536 kbps, teljesen két- 
irányú. Az ADSL-vonal az ATM magas hibajavításból adódó 
többletterhelés miatt kevésbé hatékony, mint a Frame Relay 
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3. kép A lehetséges legkisebb költség biztosítása céljából 
az ideális megoldás szerint a T1 vonal csak az idő 5906-ban üzemel 
teljes sávszélességen 


elvén működő T1. Vagyis a hasznos átvitel tekintetében 

a bejövő, azaz a letöltési sebesség a TI és az ADSL-vonalon 
hasonló jellemzőkkel bír. 

Abban a szerencsés helyzetben vagyunk, hogy az ADSL- 
vonalunk jó csatlakozástöbblet-aránnyal" bír, ezért a teljesít- 
mény egyenletesebb, mint sok hasonló kapcsolaté ("A csat- 
lakozástöbblet-arány — oversubscription — a szolgáltatók ál- 
tal eladott sávszélesség összegének és a szolgáltató 
Internetre csatlakozó sávszélességének aránya - a fordító 
megjegyzése). Ez az arány a központi irodában akár 200- 
300 szoros is lehet, ami csúcsidőszakban igen gyenge átvi- 
telt eredményez. Még a mi majdnem tökéletes ADSL kap- 
csolatunk esetén is igaz, hogy a tényleges feltöltési sebesség 
a T1-ének kevesebb mint fele, ami ésszerűvé teszi a bejövő 
forgalmat az ADSL csatlakozáson bonyolítani, míg a T1-et 
inkább megtartani a kimenő adatok számára. A sebességbeli 
különbségeken túl van még egy lényeges eltérés a Frame 
Relay T1 és az ADSL-vonal között, mégpedig az, hogy a T1 
egy kis fix IP-címtartományt is biztosít, míg az ADSL az IP- 
címét a DHCP kiszolgálótól kapja. Legalább azoknak a szol- 
gáltatásoknak a T1-vonalon kell lenniük, amelyek számára 
szükséges, hogy támogassák a rögzített IP-címre érkező ké- 
retlen bejövő forgalmat. Ilyenek például a webkiszolgálók. 
A nagy mennyiségű adatletöltéssel járó forgalmat nagyrészt 
a böngészés, levélforgalom és a bejövő FTP-forgalom teszi 
ki, amelyet a nagy letöltési sávszélességgel rendelkező 
ADSL sikerrel tud kezelni. A kivétel a kimenő SMIP forga- 
lom, amely ki tudja használni a Frame Relay T1-vonal így 
felszabaduló sávszélességét. 

Az A és B ügyfelek három kiszolgálógéppel rendelkeznek. 
Ezek közül egy Webkiszolgáló, amely rögzített IP-címmel 
kell rendelkezzen és főleg kimenő forgalmat generál. A má- 
sik egy csekély forgalmat bonyolító VPN-kiszolgáló, amely- 
nek szintén rögzített IP-címre van szüksége. Ennek a két ki- 
szolgálónak minden forgalma a T1 rögzített IP-című vonalát 
veszi igénybe. A Sangoma forgalomelosztási megoldása 
több szakaszból álló folyamat, melynek során a kimenő cso- 
magok egy sereg szabályon és intézkedésen keresztülhalad- 
va érik el a legjobb forgalomszétosztást. Csak a kimenő cso- 
magok elosztása történik meg a két vonal között, mivel 

a bejövő forgalom útvonalát nem tudjuk ellenőrizni. Igaz 
viszont, hogy ha egy csomag egy meghatározott vonalon, 
az ADSL-en vagy T1-en elhagyja a rendszert, a rá adott vá- 
lasz is ugyanazon a felületen fog megérkezni. 











1. lista Többszörös útválasztó tábla 


cat /etc/iproute2rt tables 


át 

f$ reserved values 
ht 

4255 local 
1254 main 

14253 default 
40 unspec 

$ local 

41 inr.ruhep 
200 ads! 


A Linux alatt elérhető fejlett útválasztó eszközök és segéd- 
programok módot adnak arra, hogy a megfelelő hálózatke- 
zeléssel elérhessük céljainkat. A Linux rendszermag támo- 
gatja a többszörös útválasztó táblákat, lehetővé téve, hogy 
minden egyes fizikai kapcsolat saját útválasztó táblával ren- 
delkezzen. Ha már rendelkezünk a két fizikai felületünk 
számára a különálló táblázatokkal, az iptables és iproute2 
programokkal irányíthatjuk a forgalmat a megfelelő útvá- 
lasztó táblára. Innen a csomagok az alapértelmezett utat kö- 
vetve jutnak a megfelelő fizikai felületre. 

Az iproute2 programcsomag egy beállítófájllal rendelkezik 
az útválasztó táblák és a Linux útválasztó vermének megfe- 
leltetésére. Alapértelmezésben a tr. tables egyetlen útvá- 
lasztó tábla meghatározást tartalmaz, amelynek neve main. 
Ez az alap útválasztó tábla, amelyet a Linux útválasztó ver- 
me használ. Az 1. listában látható az általunk az ADSL- 
vonalhoz hozzáadott ads1 nevű útválasztó tábla bejegyzés. 
Ehhez az útválasztó táblához szabványos Linux parancsok 
segítségével adtunk hozzá egyedi útvonalakat. A kimenő 
csomagoknak az útválasztó bemenete és kimenete között 
hat szinten kell áthaladniuk. 


Az Ethernet-hálózat felől érkező bemenet 

Az első lépés az iptables mangle-szabályának alkalmazása, 
melynek során a forgalom vagy Tag 1 címkét kap, amely az 
ADSL-t jelenti, vagy Tag 2-t a TI számára. A Sangoma 
összes levelének Tag 2-vel való megjelöléséhez például 

a következő szabályt alkalmazzuk: 


iptables 
"tap tep 


-t mangle -A PREROUTING -i eth0 
-S XXX.XXX.XXX.82 --dport smtp -j t1 line 


Ezután az iptables --set-mark kapcsolóját használjuk 
atl line láncon: 


iptables -t mangle -N t1 line 
iptables -t mangle -A t1 line -j MARK --set-mark 2 
iptables -t mangle -A t1 line -j ACCEPT 


Hasonló szabályaink vannak az ADSL-vonalra küldött for- 
galom számára is. 

Az iproute2 a Tag 1címkéjű csomagokat az ADSL útvá- 
lasztó táblájára, a Tag 2 címkéjűeket pedig a main útválasz- 
tó táblára irányítja, ami a T1-re irányítja a forgalmat: 
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4. kép A címkézés és az intelligens útválasztás lehetővé teszi, 
hogy az ADSL meghibásodása esetén a T1 vonal vegye át a forgalmat 


ip rule del fwmark 1 table adsl1 
ip rule add fwmark 1 table ads! 
ip rule del fwmark 2 table main 
ip rule add fwmark 2 table main 


Az útválasztó táblák 

Az ADSL útválasztó táblájának alapértelmezett útvonala 

a pppO, amely a PPPoE kapcsolatot képviseli. Az Ethernet 
ezután ATM-be (EoA) ágyazva folytatja útját, és ezek az 
ATM-csomagok haladnak keresztül az ADSL kapcsolaton 

a DSLAM felé. 

Amennyiben a ppp0O csatlakozóval valamilyen gond adód- 
na, az ADSL alapértelmezett útvonalát a rendszermag ön- 
működően eltávolítja, helyébe pedig a main útválasztó tábla 
lép. Így az ADSL kapcsolat meghibásodása esetén az összes 
ADSL-vonalnak szánt forgalom a feltehetően megbízhatóbb 
main útválasztó tábla felé kerül átirányításra. 

Rendszeresen előfordulnak olyan ADSL-üzemszünetek, 
amelyek az ilyen alacsony árú, ellenőrizetlen sávszélességű 
szolgáltatások velejárói. Az üzemszünetek hossza néhány 
másodperctől több óráig is terjedhet, de ez a felhasználók 
számára nem jelent hátrányt, mert a forgalom észrevétlenül 
átterhelődik a T1-vonalra. 

A TI felület az ADSL jó biztonsági tartaléka, mindez azon- 
ban fordítva már nem igaz. A T1 használatának sok gép 
esetén az az oka, hogy rögzített IP-címre van szükség, va- 
gyis a változó IP-című ADSL nem alkalmas ilyen szolgálta- 
tás nyújtására. A main útválasztó tábla alapértelmezett út- 
vonala a wan0 (T1). Minden olyan forgalom, amely erre az 
útválasztó táblára kerül, a T1-re lesz továbbítva. 


A kimenő forgalom maszkolása 

Az ADSL-kapcsolaton keresztül érkező Internet- 
forgalom olyan kiszolgálókról érkezik, amelyek IP-címe 
szerepelhet az útválasztásban. Ezeknek a címeknek cím- 
fordításon (NAT) kell keresztülesniük, különben a valódi 
IP címre irányított forgalom a T1-vonalon keresztül 
visszatér: 


iptables -t nat -A POSTROUTING -o pppO -j 
"55 MASOUERADE 


A címkézési és útválasztási eljárásunkat a 4. kép mutatja. 


Az IP-számlálás 

Miután a megfelelő forgalmat az ADSL-vonalra irányítottuk 
át, a T1-re maradó forgalmat úgy kell elosztanunk, hogy 

a felhasználás határát soha ne lépjük át. A mágikus 9575-os 


2004. szeptember 41 


0 Kiskapu Kft. Minden jog fenntartva 








Szaktekintély 


0 Kiskapu Kft. Minden jog fenntartva 
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5. kép A sávszélesség-kihasználtság 2003 májusában 
5 perces egységekben mérve 


pont nem haladhatja meg a 128 kbps értéket. Először is az 
IP-számlálás segítségével mérjük a forgalmat, ami lehetővé 
teszi számunkra a megadott időintervallumok átlagos átvi- 
telének a számítását. 

Az összes T1-vonalon kimenő vagy bejövő csomag áthalad 
az IP-számlálás szabályrendszerén. Minden ügyfél forgalma 
külön mérésre kerül az IP-címe és a forgalom iránya alapján. 
Egy egyénileg fejlesztett démon ellenőrzi az ötperces perió- 
dusokban a T1 által használt sávszélességet. Minden olyan 
esetben, amikor a T1 vonalon átmenő forgalom nagysága 
meghaladja a 128 kbps értéket az ötperces periódus átlagára 
számolva, eggyel növeljük az erre fenntartott számláló érté- 
két. A 128 kbps küszöbérték körülbelül 4,5 MB-os átvitelnek 
felel meg az öt perc alatt. 

A számláló 432-es értéke felel meg a havi 36 órának, amely 
az 590-os határ elérését jelenti, ekkor lefut a TC (traffic 
control — forgalomvezérlő) parancsfájl, amely a következő 
hónap elejéig a 128 kbps érték alá kényszeríti a T1 forgal- 
mát. Az IP-számlálás beállítófájlját a 2. lista mutatja, amely 
letölthető a Linux Journal FTP-oldaláról 
(tp.ssc.com/pubd/lj/listings/issue121/7134.tgz). 


Forgalomszabályozás a TC-vel 

Rendszerint sikerül a hónapot anélkül átvészelnünk, hogy 
a T1 forgalmát korlátoznunk kellene, de előfordul, hogy fel- 
használjuk a 36 órás ingyenes keretünket. 

Ebben az esetben a forgalomszabályozót (TC) használjuk 

a sávszélesség korlátozására. A forgalomszabályozásról 

és a tc parancsról szóló leírást a 5 http://www.lartc.org/ 
manpages címen találunk. 

A Odisc CBO (class-based gueuwing — osztályozás-alapú 
sorbaállítás) szabályait használjuk mind a wanO T1 vonal, 
mind pedig az eth0 Ethernet szabályozásához. Ezt mindkét 
kapcsolat mindkét irányú forgalmának vezérlésénél alkal- 
mazzuk: 


tc gdisc add dev wan0O root handle 10: 
s cba bandwidth 1500Kbit avpkt 1000 
tc gdisc add dev eth0 root handle 20: 
s cba bandwidth 1500Kkbit avpkt 1000 
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Sorted Bandwidth: 


6. kép A sávszélesség-kihasználtság 2003 májusában 
5 perces egységekben, sávszélesség szerint rendezve 


Következő lépésként a Global Class számára a maximális 
sávszélességet biztosítjuk a wan0 és eth0O számára is, ami 
mindkét vonal esetén 1500 kbps: 


tc class add dev wan0 parent 10:0 classid 10:1 
s cba bandwidth 1500kbit avpkt 1000 rate 1500kbit 
sallot 1514 weight 150kbit prio 8 maxburst 0 
tc class add dev wan0 parent 20:0 classid 20:1 
s cba bandwidth 1500Kkbit avpkt 1000 rate 1500kbit 
sallot 1514 weight 150kbit prio 8 maxburst 0 


Létrehozzuk a User Class osztályt mindkét vonalon 
korlátozott sávszélességgel. Az általunk használt sáv- 
szélességkorlát 100 kbps és nem 128 kbps, mivel a Linux 
TC nem teljesen pontos, és próbálgatással azt tapasz- 
taltuk, hogy ha 100 kbps értéknél nagyobbra állítjuk 

a sávszélesség határát, az átvitel időnként 128 kbps fölé 
csúszhat: 


tc class add dev wan0 parent 10:1 classid 10:100 
s cba bandwidth 1500Kkbit avpkt 1000 rate 100kbit 
sallot 1514 weight 10kbit prio 8 maxburst 0 bounded 
tc class add dev eth0 parent 20:1 classid 20:100 
scbag bandwidth 1500Kkbit avpkt 1000 rate 100kbit 
sallot 1514 weight J10kbit prio 8 maxburst 0 bounded 


Most alkalmazzuk az SFO sorbaállítási szabályt a User 
class számára mindkét (wan0, eth0) vonalon. Ehhez 

az alapértelmezett Sfochastic Fairness Oueuing (SFT) 
eljárást választottuk ki. Számos más szabály is alkalmaz- 
ható lenne: 


tc gdisc add dev wan0 parent 10:100 
s sfg guantum 1514b perturb 15 
tc gdisc add dev eth0 parent 20:100 
ssfg guantum 1514b perturb 15 


Kössük össze a 2-es számú forgalmat a User Class Oueue- 
val (felhasználói osztály sor) mind a wanO mind az eth0 
esetében. A T1 vonalnak szánt minden forgalom már meg- 








kapta a 2-es címkét. A forgalomszabályozás csak a T1 for- 
galmát korlátozza, az ADSL a teljes fizikai sebességét ki- 
használva működik: 


tc filter add dev wan0O parent 10:0 protocol ip 
sprio 25 handle 2 fw flowid 10:100 
tc filter add dev ethO0 parent 20:0 protocol ip 
sprio 25 handle 2 fw flowid 20:100 


Az elért eredmények 

Az intelligens útválasztás tökéletesen, a programozott tulaj- 
donságoknak megfelelően működik, megfelelően elosztva 

a forgalmat a T1 és ADSL kapcsolatok között és tartalékvo- 
nalat biztosítva egy ADSL-hiba esetére. A T1-en alkalmazott 
forgalomkezelés kielégítőnek bizonyult, és lehetővé tette, 
hogy a felhasználóinknak elfogadható szolgáltatást biztosít- 
sunk anélkül, hogy a beavatkozás észlelhető lenne. Termé- 
szetesen a hónap közben tapasztalt átbocsátóképesség függ 
attól, hogy az ingyenes sávszélesség milyen gyorsan kerül 
felhasználásra. 

A T1 forgalomkezelésének egy példáját mutatja az 5. kép, 
amely a T1 Frame Relay sávszélesség-felhasználásának 2003 
májusi értékeit mutatja. A grafikonon látható piros vonal 

a 128 kbps-os számlázási sávszélesség küszöbértékünket mu- 
tatja. Az átvitel korlátozására május 23-tól került sor. Az ügy- 
feleink egyik kiszolgálóját megfertőzte egy vírus, amely a hó- 
nap során igen nagy forgalmat generálva felemésztette az ér- 
tékes ingyenes sávszélességünk jó részét. Ennek eredménye- 
ként ezek az ügyfelek több mint egy hétig 128 kbps sebesség- 


korláttal voltak kénytelenek a TI vonalon kommunikálni. 
Az ADSL-forgalmat természetesen mindez nem érintette. 

A 6. képen ugyanezeket az adatokat látjuk sávszélesség sze- 
rint sorba rakva az ötperces intervallumokat. Ezt összeha- 
sonlíthatjuk a cikk elején mutatott ideális sávszélesség-fel- 
használási grafikonnal. Látható a 122,07 kbps számlázási 
érték is az ábrán, amely jelzi a forgalomkezelő eljárásunk 
sikerességét a 128 kbps alatti számlázási értéket illetően. 


Osszegzés 

Bár az intelligens útválasztás, IP-számlálás és forgalomsza- 

bályozás egy igen egyszerű megvalósításával ismerkedhet- 

tünk meg, képet alkothatunk arról, hogy a Linux fejlett út- 

választó eszközei hogyan használhatók fel kifinomult útvá- 
lasztási stratégiák kialakításához. 


Linux Journal 2004. május, 121. szám 





David Mandelstam a Sangoma Technologies Corp. elnöke. 
Az 1984-ben alapított cég WAN-eszközök (hardver és szoft- 
ver) fejlesztésére és gyártására szakosodott, ezen belül is ki- 
emelten a PC-ken használható eszközökre. Az általuk kifej- 
lesztett kommunikációs megoldások és útválasztó eszközök 
minden népszerű WAN-hálózatot, protokollt és PC operációs 
rendszert támogatnak. 


Nenad Corbic a Sangoma technologies Corp. vezető Linux- 
fejlesztője. (www.sangoma.com) 


Kapu a Linux világába 


Az eredmény alapján készítettünk egy tervezetet a CD-melléketre vonatkozó változtatásokra, 
ennek megvalósításáról a Tí szavazataitok szerint fogunk dönteni, Ezért kérünk mindetdkát, hogy 
válaszoljon néhány kérdésre ezen az öláslont 
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Biztonságos FTP-szolgáltatás üzemeltetése 


vsftpd használatával 


Ha meg szeretnéd őrizni FTP-helyed biztonságát, akkor csak névtelen hozzáféréseket 
engedélyezz, és használj minél egyszerűbb FTP-démont. 


ondolná bárki is, hogy az immár közel négy éve futó 
Ég sorozatban még nem volt szó az FTP-szolgáltatás be- 

állításáról? Most pótolom mulasztásomat, ehhez ked- 
venc FTP-kiszolgálómat, Chris Evans kiváló vsftpd-jét (Very 
Secure, nagyon biztonságos FTP démon) hívom segítségül. 
Mivel korlátozott nagyságú hellyel gazdálkodhatok, és az 
FIP legjobb használati módja a névtelen FTP ez alkalom- 
mal erre fogunk összpontosítani. A vsftpd egyre népsze- 
rűbb, hogy újabban a Debian, SuSE, Fedora, Red Hat és 
egyéb Linux-terjesztésekben is megtalálható. Térnyerésé- 
nek oka talán az, hogy egyedi módon egyesíti a biztonságot 
és a kényelmet. Üzembe helyezni mindössze néhány moz- 
dulat, és nem kényszerülünk választani a biztonság és 
a kényelem között. Chris Evans fő szempontja a vsftpd fej- 
lesztése közben a biztonság megőrzése volt, és eddigi ered- 
ményei alapján bizony jó munkát végzett. A vsftpd közel 
négy éve létezik, de komolyabb biztonsági hiányosságot s0- 
ha nem találtak benne. Mennyire minimalista a vsftpd? Tel- 
jes forráskódfájának mérete tömörítés nélkül is alig haladja 
meg az 1 MB-ot. A futtatható vsftpd fájl mérete pedig 
mindössze 80 KB. 


A vsftpd letöltése és telepítése 

Már említettem, hogy a vsftpd sok Linux-terjesztésben 
alapelemként szerepel. Ha a terjesztésekből telepítjük, a bi- 
náris csomagok használatából fakadó szokásos előnyöket él- 
vezhetjük: kényelem, könnyű foltozás, a rendszerprogra- 
mok működésének lehető legkisebb mértékű befolyásolása. 
Debian, SuSE, Fedora és Red Hat alatt logikusan a vsftpd 
nevű csomagot kell telepíteni. Különleges függőségei nin- 
csenek. A legtöbb felhasználó tökéletesen elégedett lesz 

a saját terjesztésében szereplő vsftpd csomaggal. 

Ha saját terjesztésünkben a vsftpd nem szerepel bináris 
csomagként, vagy a terjesztésben megtalálhatónál újabb 
változatot akarunk használni, akkor a 
Dhttp:/www.vsítpd.beasts.org címről kell letöltenünk 

a forrást, majd le kell fordítanunk a programot. A fordítás 
folyamata határozottan régimódi. Ha még nem tettük vol- 
na meg, váltsunk át root felhasználóra. Bontsuk ki a .tar 
állományt, majd lépjünk át a gyökérkönyvtárába, 

például így: 
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ff tar -xzf vsftpd-1.2.1.tar.gz; cd vsftpd-1.2.1 


Következő lépésként adjuk ki a make parancsot, mindenféle 
kapcsoló nélkül. Ha futása sikeres, akkor egy futtatható 
vsftpd fájlt kell találnunk az aktuális könyvtárban. Ellenőriz- 
zük, hogy a nobody (senki) felhasználó létezik-e. Ha nem, 
hozzuk létre, a program ugyanis ennek jogosultságaival fut. 
Ha még nincs ilyen, hozzuk létre a /usr/sharelempty könyv- 
tárat. Tulajdonosa a root legyen, de sem csoport által, sem 
átfogóan ne legyen írható. Ez lesz a vsftpd alapértelmezett 
chroot börtöne (jail). Hozzuk létre a névtelen FTP- 
felhasználó kezdőkönyvtárát. A SuSE hagyományosan 

a /srv/ftp könyvtárat használja, más terjesztésekben 

a /var/ftp a megszokott, de azt a könyvtárat választjuk, 
amelyiket csak akarjuk. Ezt a könyvtárat szintén a root tu- 
lajdonába kell adnunk, senki másnak nem szabad írási jo- 
got kapnia rá. Hozzunk létre egy névtelen FTP-felhasználói 
fiókot, például ftp névvel, és ellenőrizzük, hogy kezdő- 
könyvtára az előző lépésben kiválasztottal egyezik-e. Lehet, 
hogy a rendszerben már létezik ilyen fiók. A névtelen FIP- 
felhasználónak ne adjuk írási jogot saját kezdőkönyvtárára, 
és semelyik fájlnak vagy könyvtárnak nem lehet a tulajdo- 
nosa. Most készen állunk arra, hogy a vsftpd-t, valamint 

a vsftpd(8) és a vsftpd.conf(5) man oldalakat a megfelelő 
helyre másoljuk, tehát adjuk ki a make install parancsot. 

A minta vsftpd.conf fájlt kézzel másoljuk a /etc könyvtárba. 
Ha a programot önálló démonként szeretnénk futtatni, 

a /etc/init.d alatt létre kell hoznunk számára egy indító pa- 
rancsfájlt. Egyébként az inetd vagy az xinetd segítségével 
gondoskodhatunk szükség szerinti indításáról. (Lásd az 
Önálló démon vagy inetd/xinetd című részt.) 

Ha a vsftpd-t önálló démonként futtatjuk, akkor az indító 
parancsfájlt kétféleképpen tudjuk engedélyezni: RPM ala- 
pú Linux-terjesztés alatt a chkconfig, Debian GNU/Linux 
alatt pedig az update-rc.d paranccsal. Ha a telepítést RPM 
vagy deb csomagból végezzük, akkor mindezekre a műve- 
letekre önműködően sor kerül, kivéve talán az utolsót. 
Mondtam már, hogy bináris csomagokat használni jóval ké- 
nyelmesebb? Egyes terjesztéseknél az újonnan telepített 
csomagokat kézzel kell engedélyezni. Például a saját SuSE 
9.0 rendszeremen a SuSE vsítpd RPM hiába telepítette 











a /etc/init.d/vsftpd fájlt, engedélyezéséhez ki kellett adnom 
a chkconfig --add vsftpd és a chkconfig --level 35 
vsftpd parancsot. 


A vsítpd leírása 

Most nézzük meg, honnan szerezhetünk információt 

a program működéséről. Először is, a vsftpd-hez tartozik 
egy EXAMPLE/ könyvtár, amely mintabeállításokat tartal- 
maz különféle alkalmazási környezetekhez; ide értve az 
önállóan és xinetd alatt történő futtatást, valamint a névte- 
len és a helyi felhasználók kiszolgálását egyaránt. Ha 

a vsftpd-t forráskódból telepítettük, az EXAMPLE könyv- 
tárat a forrást tartalmazó könyvtárban találjuk. Ha a telepí- 
téshez bináris csomagot használtunk, akkor nagy valószí- 
nűséggel felkerült egy másolata a gépre, valahova 

a /user/share/doc könyvár alá. SuSE rendszereken 

a /usr/share/doc/packages/vsftpd/EXAMPLEE elérési úton ta- 
láljuk. Az előző részben már említettem, hogy a vsftpd-hez 
tartoznak man oldalak, a vsftpd(8) és a vsftpd.conf(5). Az 
utolsó megemlítendő forrás, az alapértelmezett (mintaként 
használható) vsftpd.conf maga is rengeteg megjegyzést tar- 
talmaz. Ugyan nem tartalmazza az összes lehetséges beállí- 
tást, de a leggyakrabban használtakat igen. Jómagam szá- 
mos vstpd-példányt bírtam már működésre úgy, hogy 

a minta vsftpd.conf fájlban csak elenyésző módosításokat 
kellett eszközölnöm. 


Onálló démon vagy inetd/xinetd 

Mielőtt magának a vsftpd-nek a beállításait megadnánk, el 
kell döntenünk, hogy önálló démonként vagy szuperkiszol- 
gálóként, tehát inetd vagy xinetd segítségével szeretnénk 
futtatni. A vsftpd korábbi változataiban a fejlesztő annak 
naplózási és hozzáférés-vezérlési szolgáltatásai miatt az 
xinetd-vel történő használatot javasolta. A vsftpd 1.2-es és 
újabb változatai már maguk is képesek biztosítani ezeket 

a szolgáltatásokat. Éppen ezért Evans most már a program 
önálló démonkérnt való futtatását javasolja. Az inetd vagy 
az xinetd használatából természetesen némi teljesítmény- 
veszteség is származik. Ez a veszteség semmivel sem 
ellentételezhető, ha dedikált FIP-kiszolgálót akarunk üze- 
meltetni, vagy úgy véljük, a rendszer terhelésének jelentős 
része fog az FTP-szolgáltatás futásából származni. 

Veszem magamnak a bátorságot, és a továbbiakban feltéte- 
lezem, hogy önálló démon futtatására rendezkedünk be. 

A megfelelő leírások részletesen taglalják az inetd-vel és 
xinetd-vel való használatot, illetve a vsftpd EXAMPLE 
könyvtárában található példabeállítások alapján is sok min- 
denre rá tudunk jönni. Érdekes módon a SuSE 9 a vsftpd-t 
alapesetben xinetd, a Debian 3.0 pedig inetd alól futtatja. 
Utóbbi választás ésszerű, hiszen a Debian 3.0 a vsftpd egy 
régebbi, 1.0.0-s változatát tartalmazza, ám a SuSE 9.0-ban az 
1.2-es változat szerepel. A Fedora és a Red Hat terjesztések- 
hez készült RPM-ek önálló démonkért telepítik a vsftpdt-t. 
Tulajdonképpen mindegy is, a vsftpd inet/xinetd alóli in- 
dításról néhány lépéssel átállítható önálló indulásra. 
Először is, mint az A vsftpd letöltése és telepítése című rész- 
ben már említettem, ellenőriznünk kell, hogy a /etc/init.d 
alatt van-e engedélyezett indító parancsfájl a vsftpd-hez. 

A Fedora Core 1 és a SuSE 9.0 csomagok tartalmaznak és te- 
lepítenek is ilyet, SuSE alatt a fájl megvan ugyan, ám az 
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xinetd alól történő futtatás miatt alapesetben le van tiltva. 
Ha a Debian 3.0 vsftpd csomagját használjuk, vagy forrásból 
végezzük a telepítést, akkor magunknak kell elkészítenünk 
az indító parancsfájlt. Ugyancsak létre kell hoznunk a megfe- 
lelő hivatkozásokat azoknak a futási szinteknek a könyvtárá- 
ban — mint például rc3.d és rc5.d —, amelyekben futtatni sze- 
retnénk a démont. Végül ki kell adnunk a chkconfig vagy 
az update-rc.d parancsot. Az átállás második lépése 

a vsftpd xinetd fájljának letiltása a disable-yes érték 
megadásával a /etc/xinetd.d/vsftpd fájlban, vagy a vsftpd so- 
rának megjegyzésbe tételével a /etc/inetd.conf állományban. 
Azt is megtehetjük, hogy teljes egészében letiltjuk az inetd-t 
vagy az xinetd-t, persze csak akkor, ha a vsftpd volt az 
egyetlen fontos alóla indított dolog. Tudom, felelőtlenség rá- 
venni valakit egy alkalmazás indító parancsfájljának engedé- 
lyezésére, míg annak biztonsági szolgáltatásai nincsenek 
pontosan beállítva. Úgy gondolom azonban, hogy az enge- 
délyezésből önmagában semmi baj nem származhat, ha az il- 
lető pontosan követi a javaslataimat, és egyelőre letiltja 

a szolgáltatást. A harmadik lépés annak ellenőrzése, hogy 

a /etc/vsftpd.conf fájlban a listen kapcsoló YES értéket ka- 
pott-e. Ezután továbbléphetünk a tényleges beállításokra. 


A vsftpd beállítása névtelen 
FTP-szolyáltatás biztosítására 
Nagy valószínűséggel mást nem is kell tennünk ahhoz, hogy 
a vsftpd-vel biztonságos névtelen FIP-szolgáltatást tudjunk 
nyújtani. Alapértelmezett beállításai kizárólag ilyen hozzáfé- 
rést engednek. Sőt mi több, alapesetben semmilyen írási pa- 
rancs végrehajtását nem engedi, és a vsftpd újabb változatai 
lehetőség szerint chroot műveletet hajtanak végre 
a /usr/shareJempty könyvtárban. Ez az egyik dolog, amiért 
a vsfttpd-t szeretem. Igazából az általa nyújtott biztonságot 
elrontani több munkával jár, mint megőrizni vagy tovább erő- 
síteni. Ha feltételezzük, hogy mindez saját terjesztésünkben 
sincs másképp, akkor csak annyit kell tennünk, hogy a névte- 
len FTP-felhasználó kezdőkönyvtárába átmásoljuk a mások- 
nak letöltésre szánt anyagokat. Debian 3.0, SuSE 9.0 és Fedora 
Core 1 alatt a névtelen FIP-felhasználó alapesetben az ftp fió- 
kot használja, kezdőkönyvtára Debian és SuSE alatt /sru/ftp, 
Fedora alatt pedig /var/ftp. Ha a telepítést forrásból végeztük, 
a névtelen FTP könyvtára az lesz, amit a névtelen FTP- 
felhasználó fiókjához kezdőkönyvtárként hozzárendeltünk. 
Az FTP könyvtárainak fájlokkal feltöltésekor ügyeljünk a tu- 
lajdonjogok és az engedélyek pontos beállítására. Előfordul- 
hat, hogy az alapértékek nem megfelelők, ám egy gyors 15 - 
al mindent elárul. Ugyan a legtöbb felhasználó számára az 
alapértelmezett beállítások tökéletesen megfelelnek, tekintsük 
át a vsftpd.conf-ban szereplő, a névtelen FTP-vel leginkább 
kapcsolatos beállításokat. Alapesetben ez a fájl a /etc könyv- 
tárban található, bár Red Hat és Fedora rendszereken 
a /etc/vsftpd/ könyvtárban találjuk. Az 1. kódrészlet egy minta 
vsftpd.conf fájlt szemléltet. A gyakorlatban a vsftpd.conf fájlt 
senki nem használja az 1. kódrészletben szereplő formában, ott 
ugyanis minden beállítás alapértelmezett értékkel szerepel. 
A kódrészletet inkább hivatkozási alapnak szántam. Lássuk 
tehát a beállításokat. 
e listen: Utasítja a vsftpd-t, hogy démonkérnt fusson, és 
ne az inetd vagy az xinetd által igény szerint, kapcso- 
latonként indított folyamatként. Alapértéke No. 
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Tisten address: Megadja azt a helyi IP-címet, amelyen 
a vsftpd-nek figyelnie kell a bejövő kapcsolatokat. 
Alapértéke "" (null), ami az összes helyi IP-címet jelenti. 
Ha több képzetes FTP-kiszolgálót szeretnénk futtatni, 
akkor értékét mindegyik képzetes kiszolgáló beállító 
fájljában meg kell adnunk. (Lásd a Képzetes kiszolgálók 
című részt.) 

anonymous. enable: Alapértéke YEs, meghatározza, hogy 
a vsftpd fogadja-e a névtelen bejelentkezéseket. Ha érté- 
ke YES vagy nincs megadva, akkor a vsftpd valódi jelszó 
kérése nélkül fogadja az anonymous (névtelen) és a ftp 
felhasználók kapcsolatait (a két felhasználó egyenértékű). 
ftp. username: A névtelen — vagyis az anonymous és az 
ftp névvel történő — FTP-bejelentkezésekhez használt fel- 
használói fiók neve. A fióknak léteznie kell a /etc/passwd 
fájlban, és érvényes, nem az adott fiók által tulajdonolt 
kezdőkönyvtárral kell rendelkeznie. Alapértéke az ftp. 
anon root: Az a könyvtár, amelybe a vsftpd chroot 
műveletet hajt végre a névtelen bejelentkezéseknél. Az 
alapérték a névtelen FTP-felhasználói fiók kezdőkönyv- 
tára (lásd az ftp. username beállítást), de az anon root 
segítségével ettől eltérő FTP kezdőkönyvtár is megadha- 
tó. Bármelyik megoldást is választjuk, a könyvtár tulaj- 
donosa ne legyen a névtelen FTP-felhasználó. 

write enable: Hacsak értéke nem YEs, egyik felhasz- 
náló sem tölthet fel semmilyen fájlt, függetlenül 

a vsftpd.conf egyéb beállításaitól. Alapértéke No. 

anon upload enable: Ha ennek értéke, valamint 

a write enable beállítás értéke egyaránt YES, akkor 

a névtelen felhasználók engedélyt kapnak fájlok feltöl- 
tésére azokba a könyvtárakba, amelyekre a névtelen fel- 
használó fiók írási engedéllyel rendelkezik. 

anon mkdir write enable: Ha ennek értéke, valamint 

a write enable beállítás értéke egyaránt YES, akkor 

a névtelen felhasználók engedélyt kapnak könyvtárak 
létrehozására azokban a könyvtárakban, amelyekre 

a névtelen felhasználói fiók írási engedéllyel rendelkezik. 
anon other write enable: Ha ennek értéke, valamint 

a write enable beállítás értéke egyaránt YES, akkor a név- 
telen felhasználók engedélyt kapnak könyvtárak átneve- 
zésére és törlésére azokban a könyvtárakban, amelyekre 

a névtelen felhasználó fiók írási engedéllyel rendelkezik. 
anon world readable. only: Ha értéke YEs, akkor 

a névtelen felhasználók nem tudják letölteni az általá- 
nos jelleggel nem olvasható fájlokat. Akkor használható 
jól, ha a névtelen felhasználók engedélyt kapnak fájlok 
feltöltésére, de nem akarjuk, hogy más névtelen felhasz- 
nálók ezeket a fájlokat letöltsék. 

anon max rate: Megadja, hogy a névtelen felhasználók 
legfeljebb hány bájt/másodperc sávszélességet használ- 
hatnak fel. Alapértelmezett értéke 0, ami azt jelenti, 
hogy semmilyen korlátozás nincs. 

idle session timeout: A felhasználók legfeljebb ennyi 
másodpercig adhatnak ki különféle FTP-parancsokat, 
mielőtt a kapcsolatot a kiszolgáló lezárná. Alapértéke 
300, de ha aggódunk a szolgáltatásmegtagadási támadá- 
sok miatt, csökkentsük. 

ascii download enable: Ha értéke YES, akkor a fel- 
használók ASCII módú letöltéseket is indíthatnak, nem- 
csak binárisokat. Alapértéke No, mivel az ASCII mód 
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1. kódrészlet A vsftpd.conf fájlban szereplő beállítások 
névtelen FTP üzemeltetéséhez 


listen-YES 

$ listen addressz 
anonymous. enable-YESs 

ftp. username-ftp 

$ anon root-[$az ftp felhasználó kezdőkönyvtára] 
write enable-NOo 

anon upload enable-NOo 

anon mkdir write enable-No 
anon other write enable-No 
anon world readable only-YES 
anon max rate-0 

idle session timeout-300 
ascii download enable-NOo 
ascii upload enable-No 
connect from port. 20-NO 
port. enable-YEs 

hide ids-NO 

1og. ftp. protocol-No 

syslog. enable-No 

max per. ip-0 

$ cmds allowed- 

local. root-/usr/share/empty 
nopriv. user-nobody 

ftpd banner-(vsFrPd 1.2.0) 


használatára szinte soha nincs szükség, hatékonysága 
pedig annyira rossz, hogy kiváló eszköz szolgáltatás- 
megtagadási támadások indítására. 

ascii upload enable: Az ASCII módú feltöltés lehető- 
sége bizonyos esetekben jól jöhet, például ha parancs- 
fájlokat akarunk továbbítani. Alapértéke ettől függetle- 
nül No. 

connect from port. 20: Az aktív módú FTP-kapcsola- 
toknál, ha egy felhasználó letölt valamit, akár csak egy 
könyvtár fájllistáját, a kiszolgáló új kapcsolatot nyit az 
ügyfél felé, és ez általában a 20-as számú TCP-kapuról 
indul ki. Alapesetben azonban a vsftpd az ilyen kapcso- 
latokat magasabb számú kapukról indítja, így nem mu- 
száj root ként futnia. Ha az alapértéket meg akarjuk 
változtatni, mert például a felhasználók ilyen jellegű 
kapcsolatindításokra fel nem készített proxyk vagy tűz- 
falak mögül érkeznek, akkor adjunk neki YES értéket. 
port. enable: Ha NO értéket adnunk neki, a PORT paran- 
csokat letilthatjuk, amivel gyakorlatilag megtiltjuk az 
aktív módú FITP-t. Alapértéke YES. 

hide ids: Ha YES értéket adunk neki, akkor a könyvtár- 
tartalmak listázásakor a felhasználók mindenhol ftp tu- 
lajdonost és ftp csoportot látnak. Szerintem nyilvános 
FTP-kiszolgálókon van értelme egyfajta rejtőzködésre 
használni, de alapértéke No. 

1og ftp. protocol: Ha YES értéket adunk neki, engedé- 
lyezzük az FTP protokollparancsok részletes naplózását. 
Ezeket a felhasználói FIP-parancsok indítják ugyan, de 
azoktól eltérők. Hibakeresési szempontból értéktelen. 











2. kódrészlet Képzetes FTP-kiszolgáló beállító fájlja 
(/etcAvsftpd.knusper) 


Tisten-YES 

Tsten. on-182.3.4 

connect from port 20-YES 

anonymous. enable-YESs 

anon root-/srv/ftp/knusper 

ftpd banner-Üdvözöllek a knusper.wiremonkeys.org 
5 FTP-helyén. viselkedj jól! 


3. kódrészlet Képzetes FTP-kiszolgáló beállító fájlja 
(/ete/vsftpd.rover) 


Tisten-YES 

"rstendon—i.2. 3.6 

connect from port. 20-YES 

anonymous. enable-NOo 

ftpd banner-Zártkörű FTP a rover.wiremonkeys.org 
S címen. Idegeneket nem fogadunk. 

4 VIGYÁZAT: Ne használd, amíg nem tudod 
spontosan, hogy mit is csinálsz! 

local enable-YEs 


e syslog enable: Normál esetben a vsftpd a naplóüzene- 
teket a /var/log/vsftpd.log fájlba írja. Ha a beállítás értéke 
YES (alapértéke NO), akkor az üzeneteket a rendszer 
syslog szolgáltatásának küldi. 

e max per ip: Megadja, hogy egy-egy forrás IP-címről 
egyszerre legfeljebb hány kapcsolatot lehet indítani. 
Valamiféle korlátozást bevezetni nem rossz ötlet, bár az 
alapérték nulla, ami korlátlan kapcsolatszámot jelent. 
Ha viszont korlátozunk, a NAT/SPAT tűzfalak mögül ér- 
kező felhasználókkal kiszúrhatunk, hiszen ők úgy lát- 
szanak, mintha egy-egy forrás IP-címről több kapcsolat 
is eredne. 

e cmds allowed: A megengedett FTP-parancsok vesszővel 
ellátott listája. Alapértéke "" (null), vagyis nincs korláto- 
zás. Csak FTP-protokoll szintű parancsokat lehet meg- 
adni, az FTP-ügyfélprogramok által gyakran kezelt pa- 
rancsokat nem. Ha például az ügyfelek tevékenységét 
a fájlok listájának lekérdezésére, a munkakönyvtár meg- 
változtatására és a fájlok letöltésére szeretnénk korlátoz- 
ni, akkor a következő beállítást kell használnunk: 
cmds. allowed-USER , LIST , NLST , CWD , RETR , PORT , OUIT. 
A 5 http:/www.nsftools.com/tips/RawFTPhtm oldalon 
kiváló ismertetőt találunk ezekről a parancsokról. 

e local. root: Üres, a root által tulajdonolt könyvtárat ad 
meg, a vsftpd ide végez chroot műveletet, ha éppen 
a fájlrendszer egyik részéhez sem igényel hozzáférést. 
Alapértéke /usr/sharelempty. 

e  nopriv. user: Kiemelt jogok nélküli felhasználó, 

a vsftpd ennek jogaival fut, ha lehetséges. Természete- 
sen vannak olyan műveletek, amelyekhez root jogokkal 
kell futnia, ilyen például a 21-es TCP kapuhoz való kö- 
tődés. A vsftpd a lehető leghamarabb lefokozza önma- 
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gát, így próbál hozzájárulni a puffer-túlcsordulásos és 
az egyéb, root-ként eredményesebben kivitelezhető tá- 
madások esélyének és sikerességének csökkentéséhez. 

e  ftpd banner: A csatlakozni próbáló FIP-ügyfeleknek 
megjelenített üzenet. Az alapértelmezett üzenet bele 
van drótozva a vsftpd-be, az 1.2.0-s változatban ez egy- 
szerűen csak (vsFTPd 1.2.0). Ha saját üzenetet szeretnék 
használni, akkor a banner. file beállításban adjuk meg 
az azt tartalmazó szöveges fájl nevét. 


A vsftpd.conf(5) man oldal az itt szereplők mellett számos 
más beállítást is ismertet. Hihető vagy sem, itt csak a fel- 
színt érintettük. 


Képzetes kiszolyálók 

Egy több IP-címmel is rendelkező gépen több képzetes FTP- 
kiszolgálót is futtathatunk. Mindössze annyit kell tennünk, 
hogy több példányban futtatjuk a vsftpd démont, mind- 
egyik példányt saját vsftpd.conf fájllal ellátva, amelyben 
megadjuk, hogy az adott példánynak melyik IP-címen kell 
fogadnia a kapcsolatokat, illetve melyik könyvtárat kell 
névtelen kezdőkönyvtárként használnia. Tegyük fel példá- 
ul, hogy a gépemnek két IP-címe van, az 1.2.3.4 és az 1.2.3.5, 
ezek rendre a knusper és a rover DNS-névhez tartoznak. 
Ebben az esetben két vsftpd beállító fájlt is használhatok, 
például /etc/vsftpd.knusper és /etc/vsftpd.rover névvel. A 2. 
és a 3. kódrészlet ezeket a fájlokat tartalmazza. 

Talán furcsának tűnhet a local enable beállítás használata 
a 3. kódrészletben. Veszélyes dolog YES értéket adni neki, 
mivel ilyenkor az FIP-bejelentkezéshez használt azonosítók 
nyílt szövegben kerülnek továbbításra. Elsősorban azért 
szerepeltetem itt, hogy bemutassam, minden képzetes ki- 
szolgáló saját beállító fájlt használ, és akár merőben eltérő 
módon is működhet. Megtehetjük például, hogy indítunk 
egy névtelen felhasználók által is írható képzetes kiszolgá- 
lót a nyilvános feltöltések számára, egy másikat pedig egy 
szigorúan csak olvasható FTP-hely fenntartásához. Ha létre- 
hoztuk a képzetes FIP-kiszolgálók saját beállító fájljait , az 
indító parancsfájlt is módosítanunk kell. Az én példakiszol- 
gálómon - innen származik a 2. és a 3. kódrészlet is — az indí- 
tó parancsfájlba az alábbi kettőhöz hasonló sorok kerültek: 


vsftpd /etc/vsftpd.knusper 
vsftpd /etc/vsftpd.rover 


Ha Red Hat vagy Fedora rendszert futtatunk, akkor ezzel 

a feladattal nem kell foglalkoznunk. Az ezeknek a terjeszté- 
seknek a vsftpd RPM-csomagjában szereplő 
letc/init.d/vsftpd parancsfájl önműködően megkeresi 

a /etc/vsftpd könyvtárban szereplő beállító fájlokat, feltéve, 
hogy .conf kiterjesztéssel látjuk el őket. 
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pClinux-ismeretek Linux-programozók számára 


Mit szólnál, ha a programjaid memóriakezelés nélküli processzorokon is futnának? 
Azt, hogy sok munka kellene hozzá? Szó sincs róla. 


z uClinux népszerűsége az utób- 
A bi időben hatalmasat nőtt, és 

egyre több fogyasztói készülék- 
ben láthatjuk viszont. Forgalomirányítók- 
ban (1. kép), webkamerákban, DVD- 
lejátszókban való használata önmagában is 
igazolja sokoldalúságát. Az olcsó, a 
uClinux futtatására alkalmas 32 bites pro- 
cesszorok terjedése további választási lehe- 
tőségeket kínál a uClinux használatán gon- 
dolkodó gyártóknak. A uClinux immár 
a 2.6-os rendszermag része, így borítékol- 
ható, hogy ismertsége tovább fog nőni. 
Egyre több fejlesztő játszadozik a uClinux használatának 
gondolatával, ezért egy olyan útmutató, amely összefoglalja 
a normál Linuxtól való eltéréseit, valamint az alkalmazásá- 
nál felmerülő buktatókat és csapdákat, rendkívül nagy ér- 
tékkel bír. A következőkben áttekintjük, hogy az uClinux 
használatára magát elszánó fejlesztőnek milyen módosítá- 
sok elvégzésére kell felkészülnie, valamint maga a környe- 
zet hogyan hat a fejlesztési folyamatra. 


Memóriakezelés nélkül 

Meghatározó és szembeszökő különbség a uClinux és 

az egyéb Linux-rendszerek között, hogy előbbi nem képes 
memóriakezelésre. Linux alatt a memóriakezelés virtuális 
memória (virtual memory, VM) használatával folyik, a 
uClinux viszont olyan rendszerekre készült, amelyek VM- 
támogatással nem rendelkeznek. Mivel a VM-kezelés álta- 
lában az úgynevezett memóriakezelő egység (memory 
management unit, MMU) segítségével történik, a uClinux 
kapcsán sokszor hallani az MMU hiányára utaló NOMMU 
(nincs MMU) kifejezést. 

VM használatakor minden folyamat ugyanarról a — valójá- 
ban virtuális — címről fut, és a VM alrendszer feladata an- 
nak figyelése, hogy ezekhez a virtuális címekhez melyik fi- 
zikai memóriaterület tartozik. Lehetséges tehát, hogy az 
egy folyamat által látott virtuális memóriaterület összefüg- 
gő, ám az a fizikai rész, amelyre leképeződik, széttörede- 
zett; sőt, még akár a merevlemezen található csereterületen 
is lehet. Mivel az önkényesen lefoglalt memória a folyamat 
címterén belül bárhová leképezhető, már futó folyamathoz 
minden gond nélkül lehet további memóriát hozzáadni. 
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1. kép. A SnapGear LITE2 VPN 
forgalomirányítón uClinux fut 


VM nélkül minden folyamatot arra a me- 
móriaterületre kell helyezni, ahonnan fut- 
ni tud. A legegyszerűbb esetben ennek 

a memóriaterületnek összefüggőnek kell 
lennie. Bővítésére általában nincs lehető- 
ség, mert előtte és utána más folyamatok 
lehetnek. Egy uClinux alatt futó folyamat 
tehát nem tudja a hagyományos Linux 
alatt futó folyamatokhoz hasonlóan növel- 
ni a rendelkezésére álló memória méretét. 
Ugyan a futtatás érdekében minden prog- 
ramot át kell helyezni, ez a művelet a fej- 
lesztő számára észrevétlen. Szükségessége 
a VM hiányából fakad, és persze szálka minden uClinux fej- 
lesztő szemében. Közvetlen következmény, hogy semmi- 
lyen memóriavédelemmel nem számolhatunk - a rendszer- 
mag és a folyamatok a rendszer tetszőleges területét össze- 
zavarhatják. Egyes processzortípusok lehetővé teszik ugyan 
bizonyos be- és kiviteli, utasítás- és memóriaterületek fel- 
használóktól való védelmét, de garanciát semmire sem ka- 
punk. A rendszer összeomlását okozó hibáknál már csak 
azok rosszabbak, amelyeket nem veszünk észre, márpedig 
a folyamatok közötti véletlenszerű memória-felülírások fel- 
derítése rendkívül nehéz feladat. 

VM hiányában gyakorlatilag csereterületet sem lehet hasz- 
nálni. Igaz, a uClinuxot futtató rendszerek esetében ez nem 
jelent túl nagy gondot, hiszen merevlemezzel vagy a csere- 
terület kihasználásához elegendően nagyméretű memóriá- 
val amúgy sem rendelkeznek. 


A rendszermag eltérései 

A rendszermagot fejlesztők számára a uClinux kevés megle- 
petést tartogat. Az egyetlen komoly különbség az, hogy az 
MMU által biztosított lapkezelési lehetőségekről le kell 
mondari. A gyakorlatban ez csak minimális mértékben 
érinti a rendszermag működését. A tmpfs például nem 
használható uClinux alatt, mert működése a VM alrend- 
szerre alapul. 

Hasonlóképpen le kell mondanunk a szabványos futtatható 
formátumokról, ezek ugyanis uClinux alatt el nem érhető 
VM szolgáltatásokat vesznek igénybe. Ehelyett egy új, egy- 
szintű formátumot kell követni. Az egyszintű formátum 
olyan sűrített futtatható formátum, amely csak futtatható 








kódot és adatokat tárol, valamint tartalmazza azokat az át- 
helyezéseket, amelyek révén a futtatható állomány a me- 
mória tetszőleges területére betölthető. 

Az illesztőprogramokat sokszor kell módosítani a uClinuxra 
való áttéréskor, ám nem a rendszermag esetleges eltérése, 
hanem a támogatandó eszközök jellege miatt. Az SMC há- 
lózati illesztőprogram például támogatja az ISA buszos 
SMC kártyákat. Ezek általában 16 bites kártyák, és valami- 
lyen Ox3ff fölötti be- és kiviteli címen érhetők el. Az illesztő- 
program könnyedén rávehető a lapka nem ISA buszos, be- 
ágyazott változatainak támogatására, de 8, 16 vagy 32 bites 
módban kell futnia, 32 bites be- és kiviteli címet kell hasz- 
nálnia, és a megszakítás sorszáma is jóval nagyobb lesz. 

(Az ISA buszos eszközök megszakítása legfeljebb 16-os le- 
het.) Tehát az illesztőprogram nagyrészt változatlan marad, 
a gép jellegzetességei miatt kisebb átültetési munkákat el 
kell végezni. Elég gyakori, hogy a régebbi illesztőprogra- 
mok a be- és kiviteli címeket rövid egészként tárolják, be- 
ágyazott uClinux alapú rendszeren viszont, ahol az eszkö- 
zök leképezett be- és kiviteli címeken érhetők el (memory- 
mapped I/O addresses), erre nincs lehetőség. 

Az mmap rendszermagon belüli megvalósítása is merőben el- 
térő. Ugyan működése a fejlesztő számára nagyjából észre- 
vétlen, mégis ismerni kell a lelkivilágát, különben előfordul- 
hat, hogy a uClinux alapú rendszereken nagyon rossz haté- 
konyságú megoldásokat fogunk kidolgozni. Hacsak a 
KClinux mmap-ja nem képes közvetlenül a fájlrendszeren be- 
lül mutatni a fájlra, biztosítva ezzel annak soros elérését és 
folytonosságát, memóriát kell foglalnia, és át kell másolnia az 
adatokat a memóriába. Az mmap uClinux alatti hatékony 
használatához bizony különleges feltételeknek kell teljesülni- 
ük. Először is, jelenleg az egyetlen fájlrendszer, amely képes 
a fájlok összefüggő tárolását biztosítani, az a romfs. Mivel 

a memóriafoglalást el akarjuk kerülni, romfs-t kell használ- 
nunk. Másodszor, kizárólag a csak olvasható leképezéseket 
lehet megosztani, vagyis — ugyancsak a memóriafoglalás el- 
kerülése miatt — a leképezések csak olvashatóklehetnek. Ép- 
pen ezért uClinux alatt a fejlesztők nem használhatják ki 

a másolás írás közben (copy-on-write) lehetőségeket. A rend- 
szermagnak is figyelembe kell vennie, hogy a fájlrendszer- 
nek ROM-ban kell lennie, amely egy csak olvashatónak kine- 
vezett terület lesz a processzor címterében. Erre akkor van le- 
hetőség, ha a fájlrendszer valahol RAM-ban vagy ROM-ban 
található. Mindkét esetben közvetlen címezhetőséget kell 
biztosítani a processzor számára. Nulla méretű mmap memó- 
riafoglalásra nincs lehetőség, ha a fájlrendszer merevlemezen 
található, hiába használunk akár romfs-t, ugyanis ilyenkor 

a processzor nem tudja közvetlenül megcímezni a tartalmat. 


Memóriafoglalás a rendszermag 

és az alkalmazások számára 

A uClinux kétféle magszintű memóriafoglalót (allocator) kí- 
nál. Első látásra talán nem egyértelmű, miért van szükség 
egy másik memóriafoglalóra is, de a kisméretű uClinux 
rendszereknél a különbség nyilvánvalóvá válik. A Linux 
alapértelmezett memóriafoglalója a kettő hatványaira épülő 
foglalási módszert alkalmaz. Működése ennek köszönhető- 
en gyorsabb, és hamar talál a foglalási kérésnek megfelelő 
méretű memóriaterületet. Sajnos uClinux alatt az alkalma- 
zásokat arra a memóriaterületre kell betölteni, amit a me- 
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móriafoglaló biztosít. A - különösen nagyméretű területek 
foglalásakor jelentkező — következményeket hamar megért- 
jük, ha veszünk példaként egy 33 KB memóriát igénylő al- 
kalmazást. A memóriafoglalásnál a kettő következő hatvá- 
nya szerint ez 64 KB memóriát fog kapri. A feleslegesen le- 
foglalt 31 KB területet nem tudjuk hatékonyan felhasználni. 

Az ilyen jellegű memóriapazarlás a legtöbb uClinux rend- 

szerben elfogadhatatlan. Az ebből fakadó gondok elkerülé- 

sére egy másik memóriafoglalót is készítettek a uClinux 
rendszermagokhoz. Általában page. alloc2 vagy kmalloc2 
névvel illetik, a tényleges rendszermagváltozattól függően. 

A page alloc2 a kettő hatványai szerint történő memória- 

foglalásból fakadó pazarlást szünteti meg. Az egy lapnyinál 

(egy lap mérete 4096 bájt, vagyis 4 KB) kevesebb memóriát 

igénylő alkalmazások számára ez is a kettő hatványai sze- 

rint foglalja a memóriát, e felett azonban a lefoglalt terület 
méretét a következő egész lapméretre kerekíti. Visszatérve 
az előző példához, egy 33 KB-ot igénylő alkalmazás 36 KB 
memóriát fog kapni, vagyis egy 33 KB-os alkalmazásnál 
azonnal megtakarítottunk 28 KB-ot. 

A page. alloc2 a memória töredezése ellen is megteszi 

a szükséges lépéseket. A két lapnyi (8 KB) vagy kisebb igé- 

nyeket a memória elejéről, az ennél nagyobbakat a végéről 

elégíti ki. Ezzel elkerülhető, hogy az átmeneti, például háló- 
zati pufferek számára végzett foglalások miatt a memória 
feltöredezzen, és később a nagyobb alkalmazások futtatása 
meghiúsuljon. Részletesebb memóriatöredezési példát lej- 
jebb, az Alkalmazások és folyamatok című részben muta- 
tok. A page alloc2 persze nem tökéletes, de a gyakorlat- 
ban remekül működik, ugyanis a uClinuxot használó be- 
ágyazott készülékeken alkalmazások egy viszonylag állan- 
dó csoportja és általában hosszú ideig fut. Miután a kedves 
fejlesztő túltette magát a rendszermag memóriafoglalási 
nyűgein, a valódi érdekességeket az alkalmazások terén 

tapasztalhatja. Itt mutatkozik meg igazán a uClinux VM- 

kezelésének hiánya. A legnagyobb különbség, ami az alkal- 

mazások uClinux alatti működését gátolja, az a dinamikus 
verem hiánya. A VM-kezeléssel rendelkező Linuxok alatt, 
ha egy alkalmazás megpróbál a verem tetején túlra írni, ki- 
vételjelzést kapunk, és a vermet újabb memóriafoglalással 
bővíti a rendszer. uClinux alatt ilyesfajta kényelemre ne szá- 
mítsunk, a vermet fordítási időben kell lefoglalni. Az a fej- 
lesztő, aki alkalmazásának kapcsán eddig talán nem is törő- 
dött a verem használatának témakörével, most kénytelen 
lesz tisztázni az ilyen vonatkozású kérdéseket. Az első do- 
log, amivel a fejlesztőknek foglalkozniuk kell, amikor újon- 
nan átültetett alkalmazásuk rejtélyesen összeomlik vagy 
rendellenesen kezd működni, az a lefoglalt verem mérete. 

Alapesetben a uClinux 4 KB-ot foglal a verem számára, ami 

egy korszerű alkalmazás esetében nagyjából a semmivel 

egyenlő. A fejlesztőnek az alábbi módszerek valamelyikével 
meg kell próbálnia növelni a verem méretét: 

1. Az FLTFLAGS - -s cveremméret: hozzáadása és az 
FLTFLAGS exportálása az alkalmazáshoz tartozó 
Makefile állományba fordítás előtt. 

2. Az flthdr -s cveremméret: parancs futtatása az alkal- 
mazás lefordítása után. 


A második jelentős eltérés, ami a uClinux alatti fejlesztést 
megnehezíti, az a dinamikus kupac (heap) hiánya — ez az 
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a terület, ahonnan a mal loc és a hasonló C-függvények 
használatával bejelentett igények kielégítése történik. 

A VM-kezeléssel rendelkező Linux-rendszerek alatt az al- 
kalmazások növelhetik folyamatméretüket, vagyis dinami- 
kus kupaccal rendelkezhetnek. Mindennek megvalósítása 
hagyományosan alacsony szintű sbrk/brk rendszerhívá- 
sokkal történik, melyekkel növelhető és megváltoztatható 

a folyamatok címterének mérete. A könyvtári függvények- 
kel — mint a mal loc — történő kupackezelés annak a memó- 
riaterületnek a felhasználásával történik, amelynek lefogla- 
lására az alkalmazás nevében meghívott sbrkO függvény 
segítségével került sor. Ha egy alkalmazásnak bármikor 
több memóriára van szüksége, akkor csak újra meg kell hív- 
nia az sbrkO függvényt. A csökkentésre a brkO segítségé- 
vel nyílik mód. Az sbrkO a folyamat végén növeli meg 

a memóriaterületet. A brkO önkényesen dönt, hogy közelí- 
ti az elejéhez a folyamat végét, vagyis csökkenti annak mé- 
retét, vagy kijjebb tolja azt, vagyis növeli a folyamatot. 
Mivel uClinux alatt a brk és az sbrk szolgáltatásai nem va- 
lósíthatók meg, egy átfogó memóriakészletből kell gazdál- 
kodni, amely alapjában véve a rendszermag szabad memó- 
riakészlete. Természetesen ennek a megoldásnak is vannak 
hátulütői. Például egy megszaladó folyamat akár a teljes 
rendszermemóriát felemésztheti. A rendszerkészletből való 
foglalás nem egyenértékű az sbrk és a brk használatával, 
ezek révén ugyanis a folyamat címterének végét toljuk ki. 
Egy normál malloc megvalósítás tehát nem felel meg, új 
megvalósításra van szükség. 

Az átfogó készletes szemléletnek nyilván előnyei is vannak. 
Az első, hogy csak a ténylegesen szükséges memóriaterület- 
re tesszük rá a kezünket, nem úgy, mint az előre foglalt ku- 
pacot használó beágyazott rendszereknél. Ez a uClinux 
rendszerek esetében rendkívül fontos tényező, hiszen me- 
mória tekintetében általában szűkösen állnak. A második 
előny, hogy amikor befejezzük egy memóriaterület haszná- 
latát, azonnal visszatehetjük a készletbe. A megvalósítás so- 
rán támaszkodhatunk a rendszermag beépített memóriake- 
zelő szolgáltatásaira is, így csökkenteni tudjuk alkalmazá- 
sunk kódjának méretét. Az új felhasználók legtöbbször 

a memóriahiány gondjába futnak bele. A rendszer ugyan 
nagy mennyiségű szabad memóriával rendelkezik, az alkal- 
mazás mégsem képes adott méretű puffer számára memóri- 
át foglalni. A hiba oka ez esetben a memória töredezése, és 
jelenleg sajnos minden uClinux alapú megoldás szenved 
tőle. A VM-kezelés hiánya miatt uClinux alapú környezet- 
ben a memória teljes kihasználása a töredezés miatt gyakor- 
latilag lehetetlen. Legjobb, ha nézünk erre egy példát. Te- 
gyük fel, hogy rendszerünk 500 KB szabad memóriával ren- 
delkezik, és egy alkalmazás betöltéséhez 100 KB-ra van 
szükségünk. Ez egy egészen hétköznapi eseménynek 
mondható. Ne feledjük azonban, hogy az igény kielégítésé- 
hez 100 KB-nyi összefüggő memóriaterülettel kell rendel- 
keznünk. Tegyük fel, hogy a memóriatérkép a következő- 
képpen alakul. Minden karakter körülbelül 20 KB-nyi terü- 
letet szimbolizál, az X-ek a rendszermag vagy más progra- 
mok által lefoglalt vagy használt részeket jelzik: 
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2. ábra uClinux futtatása Xcopilot alatt (Palm emulátor) 


Mint látjuk, van ugyan 500 KB-nyi szabad területünk, ám 

a legnagyobb összefüggő szakasz is mindössze 80 KB-os. 
Ilyen helyzet többféle módon is kialakulhat. A leggyakoribb 
ok, hogy egy program lefoglal valamennyi memóriát, majd 
nagy részét felszabadítja, és ekkor egy kisebb lefoglalt rész 
marad egy nagyobb szabad blokk közepén. A rövid ideig 
futó programok ugyancsak befolyásolhatják a memóriafog- 
lalások helyét és módját. A uClinux page alloc2 memória- 
foglalója rendelkezik egy kapcsolóval, amely pontosan az 
ilyen gondok elkerülését segíti. Ez egy új /proc bejegyzést 
hoz létre, a /proc/mem map-et, amely a lapokról és foglalási 
csoportosításukról tájékoztat. Részletes ismertetésétől hely- 
hiány miatt eltekintek, de a page. al1oc2 . c-hez a rendszer- 
mag forrásában kielégítő leírást lehet találni. 

Gyakori kérdés, hogy miért nem töredezettség-mentesítjük 
a memóriát, hogy ily módon be tudjuk tölteni a 100 KB-os 
alkalmazást. A baj az, hogy nincs VM-kezelés, vagyis nem 
tudjuk áthelyezni a programok által használt memóriaterü- 
leteket. A programok általában különféle hivatkozásokat 
tesznek a lefoglalt területeken belüli címekre, és VM- 
kezelés nélkül a memóriának mindig a megadott helyen 
kell elérhetőnek lennie. Ha átmozgatjuk a programokat, 
egyszerűen összeomlanak. A uClinux ezt a gondot nem 
tudja megoldani. A fejlesztőknek tudniuk kell róla, és lehe- 
tőség szerint kisebb foglalási blokkokat kell használniuk. 


Alkalmazások és folyamatok 

A VM-kezeléssel rendelkező Linuxok és a uClinux között 
további fontos különbség a forkO rendszerhívás hiánya. 
Ha egy fejlesztő forkO hívást alkalmazó programot szeret- 
ne átültetni, bizony sokat kell dolgoznia vele. uClinux alatt 
az egyetlen lehetőség a vforkO használata. Ugyan 

a vforkO sok tekintetben megegyezik a forkO függ- 
vénnyel, éppen a különbségek számítanak a legtöbbet. 

Ha valaki nem ismerné a forkO és a vforkO rendszerhí- 
vást: segítségükkel egy folyamat két folyamatra, egy gyer- 
mekre és egy szülőre osztódhat. Egy-egy folyamat tetszőle- 
ges számú alkalommal osztódhat, ha több gyermeket is lét- 
re kell hoznia. Amikor egy folyamat elvégzi a forkO) hívá- 
sát, aggyermek minden tekintetben a szülő másolata lesz, 














ám semmin nem osztozik vele, és mind ő, mind szülője 
függetlenül futnak tovább. A vforkO esetében más a hely- 
zet. Először is, a szülő felfüggesztésre kerül, futása leáll, 
amíg a gyermek ki nem lép vagy meg nem hívja az execO 
függvényt, az új alkalmazás indítására szolgáló rendszer- 
függvényt. A gyermek a vforkO visszatérése után a szülő 
A gyermek tehát akár meg is rongálhatja szülőjének vermét 
vagy adatszerkezeteit, ami nyilván hibát okoz. A bajt úgy 
kerülhetjük el, hogy biztosítjuk, a vforkO) meghívása után 
a gyermek soha ne térjen vissza a jelenlegi veremkeretből, 
és munkájának végén az . exit függvényt hívja meg. Az 
exit azért nem használható, mert módosítja a szülő adat- 
szerkezeteit. A gyermeknek tartózkodnia kell az átfogó 
adatszerkezetekben vagy változókban tárolt adatok módo- 
sításától, ezek a változtatások ugyanis ellehetetleníthetik 

a szülő működését. Egy alkalmazás átírása a vfork haszná- 
latára a fork helyett a legtöbb esetben vagy gyermekien 
egyszerű, vagy borzalmasan nehéz. Általánosan elmondha- 
tó, hogy ha az alkalmazás a forkO hívása után nem hívja 
meg gyakorlatilag azonnal az exec) függvényt, akkor 

a forkO - vforkO csere elvégzése előtt gondosan át kell 
vizsgálni. A uClinux egyszintű futtatható formátuma, bár 
közvetlenül nem érinti az alkalmazásokat és működésüket, 
enged néhány olyan műveletet, amelyet a normál linuxos 
ELF futtatható állományok nem. Az egyszintű formátum 
kétféle változatban létezik, teljesen áthelyezett és helyfüg- 
getlen kód (position-independent code, PIC) változatban. 

A teljesen áthelyezett változat a kódjához és az adatokhoz 
egyaránt rendelkezik áthelyezésekkel, míg a PIC változat 
csak az adatokhoz használ néhányat. A beágyazott rendsze- 
rek fejlesztői számára az egyik legelőnyösebb szolgáltatás 

a helyben futtatás lehetősége (execute-in-place, XIP). Hasz- 
nálatakor az alkalmazás közvetlenül Flash memóriáról vagy 
ROM-ból fut, valóban csak minimális, adatainak elhelyezé- 
sére elegendő memóriát igényelve. Ezzel a megoldással az 
alkalmazás kódja vagy szöveges részei több példány kö- 
zött is megoszthatók. Az XIP támogatása nem minden 
pClinuxos gépen megoldott, ugyanis a fordító részéről is 
megfelelő támogatást igényel, valamint PIC formátumú 
futtatható fájlok használatát teszi szükségessé. Amíg tehát 
adott géptípus eszközkészlete képtelen a PIC kezelésére, 
addig az XIP támogatásáról sem lehet szó. Jelenleg csak 
m68k és ARM rendszereken létezik az XIP használatához 
szükséges fejlettségű támogatás az egyszintű formátumhoz. 
A romfs az egyetlen fájlrendszer, amely képes az XIP 
pClinux alatti támogatására, ugyanis az XIP használatához 
az alkalmazásokat összefüggően kell tárolni a fájlrendszer- 
ben. Az egyszintű formátum az alkalmazások vermének 
méretét is megadja a fejállományban (flat header) mező for- 
májában. Ha növelni kell egy alkalmazás vermének mére- 
tét, akkor csupán ezt a mezőt kell átírni. Erre az fIthdr pa- 
rancs használható, a következő módon: 

flthdr -s egyszintű futtatható állomány 


Az egyszintű formátum kétféle tömörítés használatát is le- 
hetővé teszi. A teljes futtatható állományt tömörítve tudunk 
a legjobban takarékoskodni a ROM-mal. Azzal a kellemes 
mellékhatással is jár, hogy az alkalmazás teljes egészében 
egyetlen összefüggő RAM-területre töltődik be. Dönthe- 


www.linuxvilag.hu 


tünk a csak az adatszegmensre kiterjedő tömörítés haszná- 
lata mellett is. Erre akkor lehet szükség, ha takarékoskodni 
szeretnénk a ROM-területtel, de XIP-et is használni szeret- 
nénk. Az 

flthdr -z egyszintű futtatható állomány 


paranccsal teljesen tömörített futtatható állományt készíthe- 
tünk, míg a 
flthdr -d egyszintű futtatható állomány 


paranccsal az adatszegmensre korlátozhatjuk a tömörítést. 


Megosztott könyvtárak 

A megosztott könyvtárakról csak érintőlegesen szólhatok, 
de annyit mindenképpen érdemes tudni róluk, hogy 
uClinux alatt teljesen más a használatuk. A jelenleg elérhető 
megoldások a fordítóprogram részéről módosításokat, a fej- 
lesztő részéről pedig kiemelt figyelmet igényelnek. Ha meg- 
osztott könyvtárat akarunk létrehozni, legjobb, ha egy pél- 
dával kezdünk. A jelenlegi uClinux terjesztések az uC-libc 
és az uClibc könyvtárakhoz egyaránt kínálnak megosztott 
könyvtárakat. Megosztott könyvtárat létrehozni nem ne- 
héz, és mindkét könyvtár jó és könnyen érhető példát mu- 
tat rá. Mielőtt bárkinek is túl nagy várakozásai lennének, 
megemlíteném, hogy a GCC -shared kapcsolójának hasz- 
nálata nem része a megosztott könyvtárak létrehozásának, 
tehát senki ne gondolja, hogy tapasztalatból meg tudja 
oldani a feladatot. uClinux alatt a megosztott könyvtárak 
ugyanolyan egyszintű futtatható állományok, mint az alkal- 
mazások, és tényleges megosztásukhoz helyben futtatható- 
ra kell fordítani őket. A helyben futtatás lehetősége nélkül 

a megosztott könyvtárak minden őket használó alkalmazás- 
hoz külön példányban indulnak el, ami rosszabb, mint ha 
befordítanánk őket alkalmazásainkba. 


Osszegzés 

kClinuxra váltani Linuxról sokszor nem csupán a kétféle 
rendszer közötti különbségek kezeléséről szól. A uClinux 
rendszerek egyre mélyebben beágyazott rendszerek, sok- 
szor meglehetősen kevés memóriával, kisebb ROM-mal és 
szokatlan eszközökkel kiegészítve. A merevlemez elmara- 
dása és a szigorú erőforráskorlátok, párosulva a memória- 
védelem hiányával és az eltérések szövevényes rendszeré- 
vel sokszor a vártnál nehezebbé teszik a uClinux világában 
tett első kirándulást. Kezdetben a legjobb az, ha megis- 
merkedünk a uClinux emulátoraival (2. ábra) vagy olcsó 
eszközöket szerzünk be. Remélem, hogy a fontosabb kér- 
désekre rámutatva sikerül elérnem, hogy az óvatosabb fej- 
lesztők felkészültebben kezdjenek bele a uClinux megis- 
merésébe, és el tudják kerülni a leggyakoribb csapdákat és 
félreértéseket. 
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A Perl és az adatbázisok (1. rész) 


Az adatbázisok életútja a szöveges állományoktól az SOL-ig a Perl távcsövén 


keresztül nézve. 


a letünket azóta hálózzák be az adatok kezelésével 

He kapcsolatos teendők, amióta írni tudunk. Az általá- 
nos iskolában bevett szokássá vált barátság-füzete- 

ink után általában valamilyen katalógus következett, ami- 
től már csak egy lépés volt az üzleti kapcsolatainkat és napi 
teendőinket tároló határidőnapló. Ezeknek az adatoknak 
a naprakészen tartása, rendszerezése és nem utolsó sorban 
a jogosulatlan szemektől való távol tartása sok-sok ismétlő- 
dő részfeladat révén okozott unalmas perceket mindannyi- 
unk számára. A számítógép pontosan azokra a feladatokra 
alkalmazható kiválóan, amik — noha feltétlen pontosságot 
és mérnöki precizitást igényelnek — a munkavégzés során 
kevés új ötletet vagy izgalmas megoldást várnak el tőlünk. 
Röviden szólva a számítógép a mai kor tökéletes rabszolgá- 
ja. Emiatt jogos igény kényes adataink szervezésével és 
gondozásával kapcsolatos tennivalóinkat hű szolgánkra 
bízni. Ahhoz azonban, hogy valóban értékes perceket őriz- 
zünk meg magunknak a szabadidőnkből, gondos tervezés 
kell. A tervezés első lépése, hogy kiválasztjuk azokat az 
eszközöket, amelyeket fel szeretnénk használni a munkánk 
során. Az adatfüggetlenítés elvéből nyilvánvalóan követke- 
zik, hogy két, egymástól jól elkülönített munkához kell se- 
gítőót találnunk. Az egyik kizárólag az adatokra összponto- 
sít, azok tárolásával, felügyeletével és szolgáltatásával törő- 
dik. A másik közvetít a felhasználó és az első segítő között, 
azaz tolmácsolja a felhasználó kéréseit és a megadott mó- 
don kivonatolja a temérdek adatból azt, amire kíváncsiak 
vagyunk. Ebben a cikksorozatban a Perl lesz a közvetítőnk. 
A továbbiakban feltételezem, hogy nemcsak hallottál erről 
a hihetetlenül rugalmas parancsnyelvről, de már meg is 
tetted az első lépéseidet ezen a téren, így nem fogom ecse- 
telni a nyelv alapjait. A Perl azért jó választás erre a fel- 
adatra, mert a legegyszerűbbtől a legösszetettebb 
adatbáziskezelési feladatokig egyszerű és gyors programo- 
zási eszközöket bocsát a rendelkezésünkre. Emiatt nem ta- 
karja el a nyelvi megvalósítás módszere az adott megoldás 
elvi lényegét. Az első segítő személyében pedig cikkről 
cikkre új adatbáziskezelőt fogunk megismerni. A körutazás 
során az egyszerűtől az egyre összetettebb rendszerek felé 
haladunk majd, ami azonban nem jelenti azt, hogy ne le- 
hetne használni akár már a legelső részben bemutatásra 
kerülő módszereket. Az adatok kezelésénél nagyon 
könnyű abba a hibába esni, amikor valaki ágyúval lő egy 
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verébre. Mindig fel kell mérni az előre látható igényeket, és 
azokhoz választani adatbáziskezelő rendszert. A mai adat- 
bázisok legnagyobb hányadának alapjait a táblák képezik. 
Egy tábla sorok előre nem meghatározott számú, rendezet- 
len gyűjteménye. Minden sor, más néven rekord, adott 
számú mezőből épül fel, és minden mezőnek határozott tí- 
pusa van. Természetesen minden sor ugyanannyi, és 
ugyanolyan típusú mezőt tartalmaz. A mezők típusának 
szigorúsága a használt adatbáziskezelő rendszertől függ. 
Egyes rendszerek különbséget tesznek az egész, és lebegő- 
pontos számok között is, mások csak a szöveget különböz- 
tetik meg a számtól, megint mások szövegként kezelnek 
mindent. Egy adatbáziskezelőnek négy alapvető műveletet 
kell ismernie. A lekérdezés valamilyen feltételnek eleget te- 
vő rekordok összegyűjtése, illetve ezek mezőinek kiválasz- 
tása. A tárolás az adatbázisba történő új rekord felvételét 
jelenti. A módosítás során egy meglévő rekord egy, vagy 
több mezője frissül. A törlés pedig egy meglévő rekord el- 
távolítása az adatbázisból. Az adatbáziskezelő kiválasztása 
során fontos szempont, hogy az említett műveletek átlago- 
san milyen gyakorisággal kerülnek végrehajtásra. 

Legelső adatbázisunk egy sima, szöveges állomány lesz. 
Adatbáziskezelőről itt nem beszélhetünk, hiszen még az 
adatbázis belső szerkezetének épségben tartásáról is magá- 
nak a programozónak kell gondoskodnia. Egy állomány egy 
táblát tárol, melyben a rekordokat a sortörés, a rekordok me- 
zőit pedig egy előre meghatározott kitüntetett karakter, 
többnyire a kettőspont, vagy vessző választja el egymástól. 
Ennek a módszernek pont az egyszerűségében rejlik 

a szépsége. Néhány száz sor esetén, ahol a leggyakoribb 
művelet az új rekord felvétele és a lekérdezés, kevés mun- 
kával nagy teljesítmény érhető el. Létjogosultságát jelzi az 
a tény is, hogy számos komoly rendszer sarokköveit a mai 
napig ilyen adatbázisok alkotják. Elég csak a UNIX 
letc/passwd állományára gondolni, mely tökéletes iskolapél- 
dája az említett módszernek. A példák során egy olyan 
adatbázissal fogunk dolgozni, mellyel elsősorban a női szí- 
vek meghódítását tehetjük zökkenőmentessé. Az adatbázis- 
ban női ismerőseink nevét és telefonszámát fogjuk tárolni, 
továbbá egy olyan apróságot, amivel levehetjük a leányzót 
a lábáról. Először is tehát hozz létre egy minta adatbázist, 
ahol kettőspont választja el a mezőket egymástól. Ehhez 
tetszőleges szövegszerkesztőt használhatsz. 
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Most első lépésként írjunk egy Perl programot az adatok le- 
kérdezéséhez. Az alábbi szkript kiírja az adott állományból 
az összes olyan lány adatait, akinek a neve illeszkedik 

a szintén paraméterként átadott mintára. 

$1!/usr/bin/per1 -w 


use strict; 


die "Használat: " . $0 . " cadat fájl: cadány 
sneveztn" unless 2 -- GARGV; 


my $talalat — 0; 
open LANYOK, $ARGV[IO] or die "Nem tudom megnyitni: " 


s. $ARGVLO] . 95"; 


while ( cLANYOK: ) í 


chop; 
my ( $nev, $telszam, $szereti ) -— split 
(Za Sa J 
if ( $nev -- /$ARGV[1]/ ) ( 
print "Találat: " . $nev . " a(z) " . $. 
s". sorban 1"; 
print " Adatlap: " . $nev . "mm"; 
print "-——-----———" "z" x length ( $nev ) 
ng 
print " Telefonszám 1 
S $telszam . "n"; 
print " Ezzel veheted le a lábáról 78; 
s $szereti Man; 
$talalatt-; 
3 
§ 
close LANYOK; 
print "összesen " . $talalat . " találat.Mn"; 


Az, hogy a parancsértelmezőt -w kapcsolóval hívjuk meg és 
a strict modult használjuk egy lépés a kultúrált, átlátható, 
továbbá lehetőség szerint hibamentes program írása felé. 

A -w fontos figyelmeztető üzenetekkel lát el, ha kifogásol- 
ható nyelvi szerkezettel éltünk, ezért mindenképpen java- 
solt a használata. A strict modul pedig szigorú ellenőrzési 
módot ír elő az értelmezőnek. A második sorban a prog- 
ramnak átadott paraméterek számát ellenőrizzük. Ha egy 
tömböt skalárként értelmezünk, akkor a tömb elemeinek 

a számát kapjuk. Így a megadott, összefűzött karakterlánc 
jelenik meg a képernyőn, és a hibára jellemző visszatérési 
értékkel kilép a program, ha az átadott paraméterek száma 
nem egyenlő pontosan 2-vel. A $talalat nevű változóban 
fogjuk tárolni a találatok számát. Ez csupán ahhoz szüksé- 
ges, hogy a keresés végeztével megjelenítsünk egy összeg- 
ző sort. A következő sorban megnyitjuk az első paraméter- 
ben szereplő állományt olvasásra, így a továbbiakban 
LANYOK fájlleíróval hivatkozhatunk rá. Amennyiben a meg- 
nyitás nem volt sikeres, hibaüzenettel kilépünk. 
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A főciklusban soronként dolgozzuk fel a bemeneti állo- 
mányt. Minden körben a $. alapértelmezett változó fogja 
tartalmazni a beolvasott sort. Minden sorról levágjuk a sor- 
vége jelet, majd beszédes változónevekbe kigyűjtjük a re- 
kord mezőit. Ha a név mezőre illeszkedik a paraméterként 
megadott minta, akkor kinyomtatjuk a képernyőre az aktu- 
ális rekord adatlapját, továbbá megnöveljük a $talalat ér- 
tékét. A találatot bemutató jelentést a lehető legízlésesebben 
jelenítjük meg. Először a $. különleges változót felhasználva 
kiíratjuk, hogy a találat melyik sorban történt. Ezután egy 
sor kihagyással következik az adatlap. Ennek fejlécét 
hosszának megfelelően aláhúzzuk, majd kinyomtatjuk az 
egyes mezők tartalmát. A program végén lezárjuk az adat- 
bázist, utolsó lépésként pedig kiíratjuk a képernyőre a talá- 
latok számát. A megvalósítás hibája, hogy nem szerepelhet 
az elválasztó karakter egyik mezőben sem. Elképzelhető, 
hogy repülő ékezeteket szeretnél használni az adatbázis- 
ban, ekkor azonban a rövid ö betűvel gondjaid támadhat- 
nak. Erre a problémára bevett megoldás a rögzített hosszú- 
ságú mezők használata. Ez esetben elválasztó karakterre 
nincs is szükség, így átvágtad a gordiuszi csomót. A máso- 
dik programban megvalósítjuk a tárolás műveletet. Progra- 
mozási oldalról ez a lehető legkönnyebb, és az erőforráso- 
kat is ebben az esetben vesszük a legkevésbé igénybe. Ön- 
magában a tárolás művelethez nincs szükség az állomány 
beolvasására. A program egyszerűen hozzáírásra nyitja meg 
az adatbázist, és egy új sorral gazdagítja a meglévő állo- 
mányt. 

$1/usr/bin/per1 -w 


use strict; 


9 ag 80 a 

cadat fájl: clány nevez ctelefonszámz 
5 zcezt szeretism" 

unless 4 -- GARGV; 


"Használat: 


die 


open LANYOK, "sz" . 
S megnyitni: " . $ARGV[0] 


$ARGV[0] or die "Nem tudom 
nt; 


print LANYOK 
5 $ARGV[3] ) 


join C( $ARGV[1], $ARGV[21], 


VAn a 


close LANYOK; 

print "Az új lány (" . $ARGVv[1] ") felvéve." ; 
Egy kifinomultabb alkalmazásban viszont lehetséges, hogy 
nem megengedhető két azonos kulcs létezése. Ennek az el- 
lenőrzéséhez előbb az első példában bemutatott módszerrel 
végig kell futni az állományon, és mikor meggyőződtünk 
arról, hogy nincs azonos kulcs, utána hozzáfűzni az új re- 
kordot. A rekordok módosítása sima szöveges állományban 
tárolt adatbázis esetén már nehézkes. A fő gond az, hogy 
miután beolvastuk az adatokat és bemutattuk a megfelelő 
bűvészmutatványokat a kiszemelt rekordokon, a módosított 
eredményhalmazt vissza kell írni eredeti helyére. Mindezt 
természetesen úgy kell megtennünk, hogy nem veszítünk 
közben adatot. Kétféle megközelítésben foghatunk neki 

a probléma megoldásának. Az első, hogy beolvassuk a teljes 
állományt a memóriába, frissítjük a szükséges rekordokat és 
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visszaírjuk az eredményt. Ennek azonban egy nagyobb 
adatbázis esetén feltétele a hatalmas memória és egyenes 
következménye a költséges műveletek okozta teljesítmény- 
visszaesés. Járhatóbb út, ha rekordról rekordra írunk egy át- 
meneti állományba, végül ezt kicseréljük az eredetivel. 
$1!/usr/bin/per1 -w 


use strict; 


die "Használat: " . $0 . 
" cadat fájlsz clány nevez cuj telszámem" 
ssunless 3 -— GARGV; 


open REGILANYOK, $ARGV[O] or die "Nem tudom 

s megnyitni: " . $ARGV[0] KÖV 

open UJLANYOK, "5tmp." . $$ or die "Nem tudok új 
sSfájlt létrehozni.m"; 


while ( cAREGILANYOK3 ) ( 
my ( $nev, $telszam, $szereti ) - split 
(0 Zs/x sza 
if ( $nev eg $ARGV[1] ) ( 


$telszam - $ARGV[21; 
print "Módosítás történt a(z) " . $. " 
s sorban." ; 

3 

print UJLANYOK join ( ":", $nev, $telszam, 


m$szereti ); 


close UJLANYOK; 

close REGILANYOK; 

unlink $ARGV[O0] or die "Nem tudom törölni: 
5 $ARGV[0] epe 

rename "tmp." $$, $ARGV[O] or die "Nem tudok 
5 átnevezni .Mn"; 

print "Kész.n"; 


Tehát két állományt nyitunk meg a főciklus előtt. Az 
egyik, melyet a REGILANYOK. állományleíróval érünk el ké- 
sőbb, olvasásra nyitjuk meg. Ez az eredeti adatbázisunk, 
melyet a program végén felváltunk az újjal. A másik, az 
UJLANYOK azonosítójú, egy átmeneti állomány, mely az 
adott könyvtárban tmp.$$ névvel jön létre, ahol $$ 

a programunk folyamat-azonosítója. Ebbe írjuk ki egyen- 
ként a rekordokat a REGILANYOK-ból, a szükséges módosí- 
tásokat elvégezve. 

A főciklusban sorról sorra dolgozzuk fel az eredeti adatbá- 
zist. Minden sort felbontunk és ellenőrizzük, hogy szüksé- 
ges-e a módosítás. Ha igen, felülírjuk az adott mezőt és er- 
ről azonnal tájékoztatjuk a felhasználót is. Végül egyesítjük 
a szétbontott sort és kiírjuk az átmeneti adatbázisba. Javít- 
ható az algoritmus hatékonysága, ha még a felbontás előtt 
végzünk egy előzetes mintaillesztést a kulcsra. A ciklus vé- 
gén mindkét állományleírót bezárjuk. Ezután eltávolítjuk az 
eredeti adatbázist, és átnevezzük az átmenetit. Végül jelez- 
zük a felhasználónak, hogy a folyamat elkészült. Ez a meg- 
oldás meglehetősen veszélyes, hiszen ha a törlés sikeres 
volt, de az átnevezés nem, akkor csak kézi beavatkozással 
lehet megmenteni az adatbázist. 
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Már csak a törlés művelet maradt hátra. Ennél egy az egy- 
ben ugyanazt az algoritmust követjük, mint az előző eset- 

ben, leszámítva azt, hogy a feldolgozás során nem módosí- 
tunk a rekordokon, hanem csak a szükségeseket írjuk ki. 


$1!/usr/bin/per1 -w 
use strict; 


die "Használat: " . $0 . " cadat fájl: clány 
5 nevezem" unless 2 -— GARGV; 


open REGILANYOK, $ARGV[O0] or die "Nem tudom 

S megnyitni: " . $ARGV[0] VX" 

open UJLANYOK, "5tmp." . $$ or die "Nem tudok új 
sfájlt létrehozni.mn"; 


while ( cAREGILANYOK3 ) ( 
if ( /A$ARGV[11:/ ) ( 
print "Törlés történt a(z) 
s sorban. Mn"; 
next; 


J 
print UJLANYOK $ ; 


close UJLANYOK; 

close REGILANYOK; 

unlink $ARGVLO] or die "Nem tudom törölni: " 
5 $ARGV[0] "ey 

rename "tmp." $$, $ARGVLO] or die "Nem tudok 
s átnevezni .Mn"; 

print "kész." ; 


Mint látható, a költséges splitO / joinO páros helyett 
egy egyszerű mintaillesztés történt a rekord legelső mezőjé- 
re. Ha a főciklusban az átmeneti változóval kapcsolatban hi- 
ányérzeted van, képzeld odaa $ változót, mely az alapér- 
telmezett minden helyzetben. Máris látni fogod, hogy miért 
vonatkozik a ciklus elején, az if feltétel részében a mintail- 
lesztés a teljes beolvasott sor első mezőjére. 

A bemutatott megvalósítások egy további fogyatékossággal 
is rendelkeznek. Ha például két felhasználó egy-egy folya- 
mattal párhuzamosan akar törölni két különböző rekordot, 
versenyhelyzet alakul ki. Aki gyorsabb volt, annak a törlés 
művelete varázslatos módon visszavonásra kerül. Erre meg- 
oldás a Perl fIockO függvénye. Ezzel egy átmeneti zárat 
helyezhetünk az adatbázisra. A flockO két típusú zárat is- 
mer. Az egyik a kizárólagos (exclusive), a másik a megosz- 
tott (shared). Ha egy folyamat feltette a kizárólagos zárat 
egy állományra, egyetlen másik folyamat sem kaphatja 
meg, amíg a zár fel nem oldódik. A megosztott zárat párhu- 
zamosan több folyamat is megszerezheti, ám ez alatt 
kizárólagos zárat nem lehet rátenni az állományra. Több- 
nyire csak olvasó folyamatok használják a megosztott, míg 
író folyamatok a kizárólagos zárat. Sok minden szerepelt, és 
nagyon sok más kimaradt ebből az írásból. Viszont, mint 
mondani szokás, a puding próbája az evés. Kísérletezz, 
játssz, és egyre többre fogsz rájönni. Sok sikert! 


Fülöp Balázs 











Újabb GIMP ismeretek 


Az előző részben megismerkedtünk a különféle rajzeszközökkel, mintákkal, 
színekkel és színátmenetekkel, így most megtanulhatjuk, hogyan hozhatunk létre 
saját igényeinknek megfelelő újabb színátmeneteket. Szó lesz még néhány szűrő 
alkalmazásáról és az előző részből kimaradt szív is bemutatásra kerül. 


ezdjük tehát a színátmenetek létrehozásával. Ami- 
jő kor új átmenetet választunk az eszközkészletben 

(a színátmenetet jelző sávra történő kettős kattintás 
segítségével), akkor a felbukkanó párbeszédablakban talál- 
hatunk két gombot. Az egyikkel bezárhatjuk az ablakot, de 
számunkra most a másik lesz a fontosabb, amelyiken az 
Edit feliratot olvashatjuk. Érdemes megjegyezni, hogy az 
ablakot kevesebb egérmozgatással is előcsalhatjuk, mégpe- 
dig a CTRL-G billentyűk segítségével. Nagyon nagy elő- 
nyünkre szolgálhat, ha megtanuljuk a billentyűkombi- 
nációkat is, mert például ha rajztáblát használunk, akkor 
szintén egyszerűbb lenyomni két billentyűt, mint pozi- 
cionálni a ceruzával, majd a kettős kattintást alkalmazni. 
Tehát hozzuk elő a párbeszédablakot és máris kezdhetjük 
létrehozni vagy szerkeszteni a saját színátmeneteinket. 


Színátmenet-szerkesztés 

Válasszuk ki a Edit gombot, így eljuthatunk az 1. képen lát- 
ható újabb ablakhoz, amiben majd a tényleges szerkesztési 
műveleteket hajtjuk végre. 

A GIMP-ben a színátmenetek szakaszokból állnak, minden 
szakasznak van egy kezdő- és egy végpontja. A két végpont 
között található még egy jelölés, ami alapállapotban a sza- 
kasz középpontját jelzi. Az 1. képen az ablak alsó részén lát- 
ható az aktuális színátmenet, fekete háromszögek jelzik 

a szakaszok határait. Az egyes részeket a szürke sávon tör- 
ténő kattintással választhatjuk ki. Hozzunk létre egy új át- 
menetet a New Gradient gomb segítségével. A név megadá- 
sa után máris hozzákezdhetünk az átmenet szerkesztésé- 
hez. 

Kezdetben a létrehozott átmenet csak egy részből áll, ezt 
jelzi az átmenet elején és végén található fekete háromszög. 
Jól látható a szakasz középpontja is, fehér háromszögéről 
könnyen felismerhető. Alapállapotban a színátmenet kezdő 
színe fekete-, végpontja pedig fehér színű. Válasszuk ki az 
egyetlen létező szakaszunkat. A kiválasztott részen jobb 
gombbal kattintva egy elég bőséges lehetőségeket kínáló 
menüt kapunk. Itt végezhetünk el minden műveletet, ami 
a színátmenettel kapcsolatos. 

Megváltoztathatjuk a végpontok színét, ha a menüből 
kiválasztjuk a Left endpoints color vagy a Right endpoints 
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A Gradient Editor LIE 
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1. kép Színátmenetek készítése 


color menüpontokat. A szokásos színválasztó párbeszédab- 
lakban állítsuk be a kívánt színt, majd az OK gombra kat- 
tintva nyugtázzuk a műveletet. 

A színeket nem csak közvetlenül állíthatjuk be, mindkét 
végpont színét másolhatjuk különböző helyekről. A Load 
from menüben találhatjuk meg a különféle másolási forrá- 
sokat, úgymint a szomszédos szakasz közelebb eső vég- 
pontja (Left/Right neighbors right/left endpoint), a szakasz 
másik végpontja (Left/Right endpoint), az aktuális előtérszín 
vagy az előre meghatározott színek egyike. 

Ugyanígy az éppen beállított színt el is tárolhatjuk a Save to 
menüben található előre beállított helyekre. 

Szintén a jobb egérgombra előbugró menüben állíthatjuk 
be a színátmenet típusát. A Blending function for segment 
almenüben választhatjuk ki, hogy lineáris, görbe által meg- 
határozott, szinuszos, vagy másfajta átmenet legyen 
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a szakasz két végpontja között. Igazából a típus kiválasztá- 
sának a gyakorlatban ritkán van jelentősége (rövid részek 
használata esetén alig látható különbség), de mindenesetre 
a fejlesztők erre is gondoltak. 


Szakaszok felosztása 

A következő fontosabb menüpont, a szakaszok felosztására 
vonatkozik. Egy kiválasztott részt kettéoszthatunk a közép- 
pontjánál a Split segment at midpoint menüpont segítségé- 
vel vagy több egyforma részre oszthatjuk a Split segment 
uniformly menüpont választásával. Ez utóbbi esetben 

a program megkérdezi, hogy hány darabra szeretnénk fel- 
osztani a kiválasztott átmenetrészt. 

Természetesen a színátmenetből törölhetünk is részeket, 
mégpedig a Delete segment menüpont választásával, vagy 

a kiválasztott részek középpontját újra középre állíthatjuk 
a Re-center midpoints in selection pont segítségével. Ugyan- 
így, ha több részt jelöltünk ki, a Re-distribute handtles in 
selection menüpont választásával a vezérlőpontokat egyen- 
lően eloszthatjuk a kiválasztott területen belül. 

Még két hasznos menüpontot találhatunk a helyi menüben, 
az egyik a Selection operations -2 Flip selection, mellyel 

a két végpont színét felcserélhetjük. A másik pedig 

a Selection operations -2 Replicate selection menüpont, 
melynek segítségével ismételhetjük az éppen kiválasztott 
szakaszokat, miután beírtuk a kívánt ismétlések számát. 
Természetesen nem kötelező minden esetben újabb színát- 
menet létrehozásával kezdenünk a munkát, hiszen a párbe- 
szédablakban más gombok is a segítségünkre vannak. Ha 
már van egy igényeinknek majdnem megfelelő átmenet, ak- 
kor arról a Copy Gradient gombbal másolatot készíthetünk, 
és ezt szerkeszthetjük tovább. A Rename Gradient gombbal 
átnevezhetjük már meglévő színátmeneteinket, míg a Delete 
Gradient gomb alkalmas arra, hogy egy elkészített színátme- 
netet töröljünk. Mivel a GIMP készítői elég körültekintően 
tervezték meg a programot, találhatunk itt egy elsőre furcsá- 
nak tűnő felirattal rendelkező gombot is. A Save as PoV-Ray 
gombról van szó, ami arra alkalmas, hogy a színátmenetet 

a PoV-Ray által értelmezhető formában mentsük el. Később 
ezt felhasználhatjuk a sugárkövetéssel számított képeinknél, 
ahogyan azt a 2. képen is láthatjuk. 


Kép, átalakítás 

Miután megismerkedtünk a színátmenetek létrehozásának 
módszerével, érdemes egy kicsit elmélyedni a GIMP képát- 
alakításra szolgáló lehetőségeiben. 

A képen a jobb gombbal kattintva elővarázsolhatjuk azt 

a menüt, melyben a különféle szűrők találhatók. Kezdjük 
talán az elején, és tekintsük át a Blur pontban található kü- 
lönféle elmosásra szolgáló megoldásokat. 

A Motion Blur segítségével olyan hatást hozhatunk létre 

a képen, mintha az mozgás közben készült volna. A moz- 
gás típusa lehet egyenes vonalú (Linear), de beállítható 
olyan hatás is, mintha a kép készítése közben közeledtünk 
(vagy távolodtunk) volna a tárgyhoz a Zoom pont választá- 
sával, esetleg készíthetünk forgás közben látszó elmosódást 
is, ha a Radial módot választjuk. Minden esetben megad- 
hatjuk az elmozdulás mértékét és az irányát, de értelem- 
szerűen forgó mozgás meghatározásakor nincs túl nagy 
hatása a szög változtatásának. 
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2. kép A GIMP és PoV-Ray 


A Blur adott sugárral és azonos súlyozással átlagolja a kép- 
pontokat, ezzel éri el a kép lágyabb megjelenítését. Például 
alkalmazhatjuk akkor, amikor több részletből rakunk össze 
valamilyen képet és az egyes részek közötti éles eltéréseket 
szeretnénk finomítani. 

A Gaussian Blur hasonló az előbbi szűrőhöz, de ebben az 
esetben az egyes képpontokhoz tartozó súlyozó tényezőket 
a program egy Gauss-görbe alapján számítja ki. 

A Pixelize talán nem újdonság, nagyon sok képfeldolgo- 

zó programban találkozhatunk hasonló megoldással. 

A képpontokat adott méretű négyzet alakú területekkel 
helyettesíti, így ha messziről nézzük a képet, akkor látható 
az eredeti tartalom durva közelítése. 

A Selective Gaussian Blur a Gauss-görbe szerinti súlyozást 
az éppen feldolgozott képrészlethez igazítja a GIMP szürő 
segítségével, így ahol kisebbek az eltérések, ott nem mosó- 
dik el annyira a képrészlet, mint a nagy eltéréseket tartalma- 
zó képterületek esetében. Lényegében ennyit érdemes tudni 
a különféle elmosásra alkalmas szűrőkről, viszont a most kö- 
vetkező szűrési műveletek igen hasznosak lehetnek. 
Vegyük sorban a Color menüben található különféle esz- 
közöket. Az első érdekes szűrő a Colorify ponton keresztül 
érhető el. A szűrőnek megadhatunk egy színt, amivel az 
egész képet vagy a kiválasztott területet átszínezhetjük. 

A meglévő színek nem vesznek el, csak egy kicsit átalakul- 
nak a megadott színhez közelebbi tartományba. 

A Value Invert a kép világosságértékeinek invertálására 
használható. A szűrő nem változtatja meg sem a színezetet, 
sem pedig a telítettséget. 

Ebben a menüben, mely a színekkel kapcsolatos szűréseket 
tartalmazza, a következő hasznos menüpont a Map. Ennek 
a pontnak szintén több alpontja van, így most ezekkel kell 
egy kicsit foglalkoznunk. 

Az Alien Map és az Alien Map 2 érdekes ugyan, meglepő 
hatásokat érhetünk el a kép különféle átszínezésével, de 
mindeddig gyakorlati hasznát nem láttam. 

Ennél sokkal hasznosabb a Color Exchange, mellyel egy 
adott színnek megadhatunk valamilyen tűrést mindhá- 
rom összetevőjéhez, majd az így meghatározott színtarto- 
mányt másik színnel helyettesíthetjük. Így kereshetünk 
egy adott színű területet is, vagy csak egyszerűen kicserél- 
hetjük valamilyen tárgy színét. 

















3. kép Vázlat a Városligetről 


A Gradient Map az éppen aktuális színátmenet színeihez 
igazítja a kép színeit. 

A Sample Colorize segítségével egy megadott minta színei- 
hez tehetjük hasonlatossá a képünk színeit. A párbeszédab- 
lakban a jobb oldalon adhatjuk meg a mintát, ami lehet egy 
tetszőleges kép, egy színátmenet vagy a kiválasztott átme- 
net inverze. Ha forrásként egy másik képet adunk meg, azt 
még a szűrő alkalmazása előtt meg kell nyitni a GIMP-ben. 
A megnyitott képen ki is választhatunk valamilyen 
részletet, így a program csak a kiválasztott területen talál- 
ható színeket veszi figyelembe. Miután meghatároztuk 

a mintaképet vagy átmenetet, kattintsunk a Get Sample 
Colors gombra, így a program előnézeti ablakában már 
láthatjuk a hatást. 

A Noise menüpont almenüin keresztül különféle zajhatáso- 
kat adhatunk a képhez. 

A HurIl leginkább a színes televízió zajához hasonlatos ered- 
ményt produkál, mintha nem lenne pontosan beállítva 

a csatorna. A Noisify beállításainál vörös, zöld és kék csator- 
nánként külön-külön adhatjuk meg a kívánt zaj mértékét. 
A Pick hatására a program a képnek azokat a részein növeli 
a zaj mértékét, ahol színek és árnyalatok hirtelen változnak. 
Ilyen helyeken az élkereső algoritmusok éleket feltételez- 
nek, tehát ha a zajt megnöveljük, akkor az élkeresés ered- 
ménye is jobban láthatóvá válik. Például ha egy szürkeár- 
nyalatos képen alkalmazzuk a Pick, majd az Edge Detect -: 
Sobel és az Enhance -2 Sharpen szűrőket, végül az egész ké- 
pet invertáljuk, akkor máris láthatjuk némi hasznát a Zaj- 
keltésnek, és megcsodálhatjuk első digitális vázlatunkat, 
ami meglepően hasonlít majd az eredeti képre. 


Elek kiemelése 

Nézzük most meg, mi is az élkiemelés. A módszer lényege, 
hogy ahol hirtelen változások vannak a szomszédos kép- 
pontok között, ott élt tételezünk fel és ezt más színnel 
jelöljük. A hirtelen változásokra úgy deríthetünk fényt, 
hogy a szomszédos pontok színeinek távolságát kiszámítjuk 
és ezt egy előre meghatározott küszöbértékhez hasonlítjuk. 
A ,színek távolsága" talán némi magyarázatra szorul. Min- 
den képpont egy vörös, egy kék és egy zöld összetevő alap- 
ján kapja a végleges színét. Vagyis minden szín ábrázolható 
egy háromdimenziós koordinátarendszerben, ahol az egyes 
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tengelyeknek a színt alkotó összetevők felelnek meg. Az 
egyszerűség kedvéért a koordinátarendszer értelmezési tar- 
tományának alsó határa legyen 0. A maximális érték, amit 
mindhárom összetevő felvehet, legyen 1. Így a három di- 
menziós rendszerben a Pxyz—(0,0,0) pont a fekete színnek 
felel meg, a Pxyz—(1,1,1) pont pedig a fehérnek. Két szín 
(melyek adottak r1,g1,b1 és r2,g2,b2 összetevőikkel) távol- 
ságát kiszámíthatjuk a következő képlet segítségével: 


D-SORT((r2-r1)A2--((g2-g1) A2--(b2-b1) A2) 


A képletben szereplő SORT függvény a négyzetgyökvonás 
számítástechnikában alkalmazott megnevezése. Tehát a ké- 
pen végighaladva megvizsgáljuk a szomszédos képpontok 
színeinek távolságát és ha az egy adott határ felett van, ak- 
kor élként jelöljük a pontot. Ezt a műveletet először elvégez- 
zük vízszintes, majd függőleges irányban haladva az eredeti 
képen és a kapott eredményeket egy képben egyesítjük. Ez 
a módszer az egyik legáltalánosabban használt élkeresési el- 
járás, a GIMP-ben is megtalálhatjuk az Edge Detect -2 Sobel 
menüpontokat követve. 


Képtisztítás 

A következő említésre méltó menüpont segítségével külön- 
féle zajtípusokat távolíthatunk el a képeinkről. Az Enhance 
menütől és annak alpontjairól van szó, ahol az első szembe- 
tűnő idegen szó a Deinterlace. Ezzel akkor találkozhatunk, 
ha valamilyen vízszintesen nagy sebességgel mozgó tárgy- 
ról készítünk képet. Bizonyos kamerák érzékelőinek az a sa- 
játossága, hogy a képsorokat nem egymás után továbbítják 
a feldolgozó egységnek, hanem először a páratlan, majd 

a páros sorokat olvassák ki. Ezt hívjuk váltott-soros kiolva- 
sásnak és a hátránya az lehet, hogy a nagy sebességgel 
mozgó tárgyak a páros sorok kiolvasásakor már elmozdul- 
hatnak. A képen, a kiolvasási módnak köszönhetően min- 
den második sorban eltolódást vehetünk észre. 

A probléma megoldására különféle eljárásokat dolgoztak ki, 
így a GIMP-ben is megtaláljuk a lehetőséget, a fent említett 
menüpont alkalmazásával. 

A Despeckle szűrő olyan esetekben tehet jó szolgálatot, ami- 
kor különféle, nem kívánatos foltok jelennek meg a képein- 
ken. A szűrő alkalmazásakor ezek a foltok ugyan nem tűn- 
nek el teljesen, de elmosódottabbá válnak, így nem annyira 
Zavaró a jelenlétük. 

Az NL Filter mindhárom típusa főként természetes képek 
minőségének javítására alkalmas, zajos képeken látványos 
javulást érhetünk el a használatával. 

Említésre méltó még a Sharpen, ami tulajdonképpen az el- 
mosás ellentéte, hatására a kép élesebbé válik. 

Érdekes próbálgatásokra ad lehetőséget a Generic menü- 
pont alatt található egyetlen szűrő, ahol saját magunk hatá- 
rozhatjuk meg, milyen súlyozással számítsa ki a program 

a képpontok új értékét. Érdemes vele próbálkozni egy ki- 
csit, ha másért nem is, legalább azért, hogy jobban megért- 
sük a szűrők működését. A táblázatba beírjuk a súlyozáshoz 
használni kívánt értékeket, majd a GIMP képpontról-kép- 
pontra kiszámítja a súlyozott átlagot figyelembe véve az ép- 
pen vizsgált képpont környezetét is. A képpont új színe az 
így kiszámított átlagos érték lesz. Figyeljük meg, hogy ha az 
súlyozó tényezők összege 1, akkor a kép élesebbé válik 
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4. kép A szív mely értünk dobog... 


(akár dombormű-szerű hatást is elérhetünk), míg ha egytől 
különböző pozitív szám, akkor a kép homályosabb lesz. 
Élkeresésre is használható a szűrő. Például ha a táblázat 
jobb oldalán csak pozitív számokat adunk meg, a balolda- 
lon pedig ugyanezen számok ellentettjét, akkor a szűrő 

a függőleges éleket emeli ki. 

A szűrő alkalmazása előtt ne felejtsük el a párbeszédablak 
jobb oldalán található vezérlők segítségével kiválasztani, 
hogy melyik színcsatornákra szeretnénk alkalmazni a meg- 
adott paramétereket. 

Nos, egyelőre ennyit mára a szűrők tanulmányozása terén, 
és most gyorsan készítsünk egy egyszerű képet a GIMP ál- 
tal rendelkezésünkre bocsátott eszközök segítségével. 


A gyakorlatban 

Sok esetben megkímélhetjük magunkat felesleges modelle- 
zési munkáktól, ha jó elboldogulunk a színátmenetek és 

a kijelölések alkalmazásával. 

Nem szükséges ugyanis olyan tárgyakat modellezni, ame- 
lyek képét csak egyszer vagy egy nézőpontból nézve hasz- 
náljuk fel. Minden eszköznek megvan a maga alkalmazási 
területe és ha valamit meg tudunk oldani egyszerűbben, 
akkor ne bonyolítsuk az életünket. 

Ilyen egyszer használatos tárgyak például kétdimenziós já- 
tékokban fordulnak elő, de olyan képekről is beszélhetünk, 
amiket valamilyen dokumentumba illesztünk be, és azok 
tartalma nem változik. Más kérdés az, ha a játékunkat vala- 
mikor majd továbbfejlesztjük és térbeli tárgyakra lesz szük- 
ség. Ha ilyen terveink vannak, akkor érdemes elgondolkod- 
ni a 3D modellezésen. Ebben az esetben is lehetnek kétdi- 
menziós nézeteink, beilleszthetjük őket dokumentumokba 
és a későbbiekben a befektetett idő megtérül. 


Rajzoljunk szívet! 

Lássuk, hogyan állítható elő a 4. képen látható szív. A kép 
megtervezésének első lépése legyen, hogy egy egyszerű 
vázlatot készítünk az elképzelésünkről. Itt akár szöveges 
megjegyzéseket is használhatunk, a lényeg az, hogy meg- 
könnyítsük a későbbi munkálatokat. 

A következő lépésben megpróbáljuk elemeire bontani a ké- 
pet. Esetemben látható, hogy egy háttérből, egy aranyszínű 
keretből és egy szívformából tevődik össze a kép. Ezt köve- 
tően nagyjából körvonalazódik bennünk, hogy mennyi ré- 
teget veszünk igénybe. A fentiek alapján legalább hármat. 
Kérdéses lehet, hogy hogyan állítsuk elő a szív körvonalát. 
Javaslom a Bezier-select eszköz használatát, amelyről az 
előző részben bővebben szóltam. 
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5. kép ...és a vagyon 


Hozzunk létre a háttéren kívül még két réteget, és 

a középsőn rajzoljuk meg a szív egyik felét. Mivel 

a szívforma tengelyesen szimmetrikus, ezért elég csak 

az egyik felét megrajzolni. Ezután a kiválasztott területet 
fessük ki egyszínűre, majd másoljuk le (CTRL-C) és il- 
lesszük be újra a képre (CTRL-V). Még mielőtt a réteg- 
hez csatolnánk, tükrözzük a függőleges tengelyre, 

hogy a szív másik fele is elkészüljön. Helyezzük el 

a másik fél mellé úgy, hogy a középvonaluk mentén 
összeérjenek. 

Következhet a keret létrehozása. Válasszuk ki az egész 
szívet, majd váltsunk át eggyel feljebb lévő rétegre. Itt 

a kiválasztott területből készítsünk keretet (Jobb gomb -: 
Selection -2 Border), és az így elkészített keretet színezzük 
ki valamilyen tetszőleges színátmenettel. Az én esetemben 
az átmenet neve Golden és a GIMP beépített színátmenetei 
között található meg. 

Váltsunk vissza a középső rétegre és válasszuk ki a szív- 
formát. Szintén valamilyen átmenttel kell kifesteni, az 

én megoldásomban ez egy előtérből-háttérbe típus volt, 
a színek előzetes beállításával, gömbszerű átmenet alkal- 
mazásával. 

Ezek után már csak a tetszőleges háttér létrehozása van 
hátra, ez bizonyára senkinek nem okoz gondot. 

A háttér ízlés szerint díszíthető, ha azonban internetes ol- 
dalainkon is szeretnénk használni a képet, akkor érdemes 
a tervezett weboldal háttérszínének megfelelőre készíteni 
a háttér széleit. Ugyanez a javaslatom más dokumentumok- 
ban való felhasználás esetére is. 


Osszegzés 

Az ilyen és ehhez hasonló egyszerű grafikák elkészítése 
azonos módszert igényel. Röviden összefoglalva tehát 

a vázlat alapján rétegekre bontjuk a képet, majd az egyes 
rétegeket lépésről lépésre felépítjük, kihasználva a szim- 
metriából származó egyszerűsítési lehetőségeket. 
Ugyanezzel a módszerrel készült az 5. képen látható ikon is. 
További kellemes ismerkedést és alkotást kívánok, és a kö- 
vetkező számban ismét jelentkezem. Addig is várom az ész- 
revételeket, kérdéseket a dzooli(gfreemail.hu címen. 





Fábián Zoltán (dzooliofreemail.hu) 

26 éves, jelenleg oktatóként dolgozik, 
szabadidejében szívesen foglalkozik Blenderrel, 
programozással és elektronikai tervezéssel. 
Szereti a természetet, túrázást, úszást és a 
kellemes baráti társaságot. 























Számítógéphálózatok 949. rész) 
Csúszóablakos protokollok, HDLC, SLIP, PPP 


Amint azt az előző számban ígértük, ezúttal folytatjuk az adatkapcsolati protokol- 
lokkal való ismerkedést, de most már olyanokat is bemutatunk, amelyek a való 
életben is megállják a helyüket. Például az interneten nagy népszerűségnek 


örvendő SLIP és PPP 


(piggybacking) módszert, amelynek köszönhetően csök- 
kenthettük a kimenő keretek számát. 

Egy csatorna kihasználtságát azonban nem csak úgy növel- 
hetjük, hogy kevesebb keretet küldünk. Az eddig ismeretett 
összes protokollban az volt a közös, hogy a csatornán egy 
időben mindig csak egy adatkeret, majd egy azt követő 
nyugtakeret volt. 

Sokkal hatékonyabb lenne, ha a csatornán egyszerre több 
keret is haladhatna. Az úgynevezett csúszóablakos (sliding 
windows) protokollok ezt teszik lehetővé. 


lőző írásunkban elemi adatkapcsolati protokol- 
lokkal foglalkoztunk. Sokféle keretátviteli mód- 
szert megvizsgáltunk, beleértve a ráültetéses 


Csúszóablakos protokollok 

A csúszóablakos protokoll a következő elven működik. 
Minden elköldött keret tartalmaz egy sorszámot, amely a 0 
és valamilyen maximális érték közé esik. A forrás minden 
elküldött keret sorszámát beteszi egy halmazba. Ez a hal- 
maz az úgynevezett adási ablak (sending window), amely- 
hez azok a keretek tartoznak, amelyeket ugyan már elküld- 
tünk, de a vevő még nem nyugtázta őket. Amikor a hálózati 
rétegtől új csomag érkezik, akkor az adatkapcsolati réteg ki- 
osztja neki a következő sorszámot, majd az ablak felső szé- 
lét feljebb csúsztatja. 

Vessünk egy pillantást az 1. ábrára. Itt a kiosztható sorszá- 
mok 0 és 7 közé esnek. Az adási ablakban jelenleg a 4., 5., 
6., 7., 0., 1. és 2. keretek vannak. Ezeket már útjukra bocsá- 
tottuk és csak a nyugtákra várunk. Amikor egy nyugta 
megérkezik, akkor az ablak alsó széle eggyel feljebb csúszik, 
így küldhetünk további kereteket. 

A vevő is karbantart egy listát, amelyet vételi ablaknak 
(receiving window) nevezünk. Ebben azon keretek sorszá- 
mai szerepelnek, amelyeket elfogadhat. Ha egy olyan keret 
érkezik, amelynek a sorszáma nincs a vételi ablakban, azt 
azonnal eldobja. Ha az érkezett keret sorszáma mégis ben- 
ne van az ablakban, a fogadó csak akkor küld nyugtát, ha 
egyrészt az adott keret még nem került nyugtázásra, más- 
részt ha minden olyan keretet vettünk, amelyek sorszámai 
az elsőnek várt és a most érkezett közé esett. 


www.linuxvilag.hu 






























































Elküldött keret Elküldendő Elküldendő keret 
€——— s —— keretabak  --——— 
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Utolsó Az ablak összemegy Az ablak kitágul 
küldöttkeret a keret elküldésekor 








1. ábra Adási ablak 








fe, Hredetüablak — a 


Nyugtázva [——— Újablak szassesző] 








2. ábra Vételi ablak 


Szegezzük tekintetünket a 2. ábrára! Az aktuális ablak első 
eleme a 3. Ha mondjuk beérkezik az 5. sorszámú keret, csak 
akkor küldünk róla nyugtát, ha már beérkezett a 3. és az 5. is. 
Ha pont egy olyan keret érkezik, amelynek sorszáma pont az 
ablak alsó szélével egyenlő, akkor arról azonnal küldhetünk 
nyugtát, és az ablakot eggyel elcsúsztathatjuk. 

Vegyük észre, hogy a vevőnek nem kell minden keretet 
nyugtáznia. Visszatérve a 2. ábrára, ha a forrás megkapja 

a 6-os kerethez tartozó nyugtát, akkor az egyben a 4-es és 5- 
ös keretek nyugtázását is jelenti. 

Egy másik érdekes dolog, hogy míg az adási ablak mérete 
folyamatosan változik, addig a vételi ablak mindig ugyanak- 
kora marad. Az adási ablak mérete azonban sohasem mehet 
a kiosztható legnagyobb sorszám fölé (ami jelen esetben 7). 
Ha eléri a maximális méretét, akkor az adatkapcsolati ré- 
tegnek ,le kell kapcsolnia" a hálózati réteget, azaz nem 
szabad engedni, hogy az további csomagokat adjon át 
továbbítás végett. 
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Mivel a keretek útközben elveszhetnek, a forrásnak az adá- 
si ablakba eső kereteket a memóriában kell tartani. Minden 
kerethez indítania kell egy időzítőt, amelynek lejártáig 

a nyugtának meg kell érkeznie. Ha ez mégsem történik 
meg, akkor a keretet ismét el kell küldeni. 


Egybites csúszóablakos protokoll 

Ez az összes ilyen jellegű protokoll között a legegyszerűbb. 
Itt minden ablak mérete maximum 1 lehet. A protokoll mű- 
ködése sokban hasonlít az előző részben bemutatott megáll- 
és-vár protokolléhoz. 

Igaz, hogy itt az adatkeretek mindkét irányba mehetnek, de 
a következő keret csak akkor kerül elküldésre, ha az előzőt 
a vevő már nyugtázta. A nyugtát azonban hordozhatja egy 
ellenirányú adatkeret. Mivel egy keret indításának feltétele, 
hogy az előző nyugtázva legyen, ezért a sorszám értéke 
csak 0 vagy 1 lehet. 

Nézzük, hogyan is működik ez a protokoll. 

Legyen a kommunikációban részt vevő két gép neve A és 
B. Először az A kezdi meg az adást, így elküldi az első adat- 
keretet B-nek. Az adatkeretbe betesz egy nyugtát, ezzel el- 
hitetve B-vel, hogy az előző keret küldése sikeres volt, így 
B is elküldi az első keretet (amely egyben A első keretének 
a nyugtája is). Ezután A veszi B keretét, majd küldi a követ- 
kezőt. De mi történik akkor, ha elveszik egy keret? Például 
az A elküldte a 0-ás sorszámú keretet B-nek, ami rendben 
meg is érkezik, a nyugta azonban elvész. Így előbb vagy 
útóbb lejár A időzítője, és ismét elküldi ugyanazt a keretet. 
B vételi ablakába azonban már az 1-es keret esik, így a dup- 
likátumot szó nélkül eldobja. 

Ezután a B küld A-nak egy keretet, amelynek sorszáma 1, 
és egyben a 0-s keret nyugtája. Amikor ez megérkezik 
A-hoz, A elküli a következő keretet. Láthatjuk tehát, hogy 
hiába veszik el bármelyik keret, a protokoll biztosan nem 
fog kihagyni egyet sem, és nem fog kettőzött keretet átadni 
a hálózati rétegnek. 

Duplikátumok küldéséhez vezethet azonban az a sajátos 
eset, amikor A és B az első keretet egyszerre küldik el. Az 
első keretek ugyanis 1-es nyugtát tartalmaznak a várt 0 he- 
lyett, ezért duplikátumok keletkeznek (3. ábra). 


Az n-el visszalépő és a szelektív ismétlő protokoll 

Az egybites csúszóablakos protokoll csak abban az esetben 
lehet hatékony, ha a keret és a visszaküldött nyugta 
célbaérésének együttes ideje elhanyagolható. Ez azonban 
nem mindig van így. Műholdas átvitel esetén például a ke- 
retek átviteli ideje olyan nagy, hogy a fent bemutatott mód- 
szerrel a sávszélességnek csupán 490-át használhatjuk ki 
(ha 50 kb/sec-os műholdas csatornát használunk). 

Ezen úgy tudnánk javítani, ha nem követelnénk meg az 
adótól, hogy csak akkor küldhet el egy keretet, ha az előzőt 
a vevő már nyugtázta. Engedjük meg inkább azt, hogy az 
adó egyszerre több, legfeljebb m darab keretet bocsáthasson 
a csatornára, majd csak ezután blokkoljon addig, amíg 

a nyugták meg nem érkeznek. 

Ha ezt az m-et ügyesen választjuk meg, akkor az első keret 
körülfordulási ideje alatt folyamatosan tudunk további ke- 
reteket továbbítani anélkül, hogy betelne az adási ablak. 
(Egy keret körülfordulási idején a keret elküldésétől 

a nyugta beérkezéséig eltelt időt értjük). 
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3. ábra Példa az 1 bites csúszóablakos protokoll működésére 


Maradjunk az előző példánál, melyben egy 50 kb/sec-es 
műholdas csatornán szeretnénk kereteket továbbítani. Te- 
gyük fel, hogy egy teljes keret elküldése 20 ms-ig tart, és 
egy keret körülfordulási ideje 500 ms. Nézzük meg, mi tör- 
ténik ha az előző protokollt használjuk. Ha a kezdő pilla- 
natban elküldjük az első keretet, akkor a 270-edik ms-ban 
érkezik meg a vevőhöz. 

Ha a vevő valamiféle mesebeli masina, amely várakozás 
nélkül képes a nyugta visszaküldésére, és a nyugta is meg- 
lehetősen rövid (legalább annyira, hogy nem kerül időbe 

a csatornára ráhelyezni), akkor pontosan 520 ms múlva ér- 
kezik a forráshoz a nyugta. 

Ekkor küldhetjük csak a második keretet, azaz körülbelül 
félmásodpercenként küldhetünk egyet. (Feltéve ha nem ve- 
szik el útközben). 

Ha megengedjük, hogy az adó egyszerre több keretet is 
küldhessen, akkor sokkal jobb eredményt érhetünk el. Ha 
továbbra is 20 ms-ig tart egy keret elküldése, akkor 520 ms 
alatt 26 keretet küldhetünk. Mikor a 26. keretet elküldtük, 
akkor meg is érkezik az első keret nyugtája. Így ha az m ér- 
tékét 26-nak választjuk, mindig akkor kapjuk meg az enge- 
délyt a következő keret elküldésére, amikor kell. 

Mivel mindig 25, illetve 26 nyugtázatlan keret van kint, ha 
az adási ablak maximális méretét 26-nak szabjuk meg, az 
sohasem fog betelni (az adó nem fog blokkolni). Így 25-ször 
nagyobb hatékonyságot értünk el, mint az egybites 
csúszóablakos protokoll használatával. Ez a techinka csőve- 
zetékezés (pipelining) néven híresült el. 

Ez így nagyon meggyőző, de érdemes belegondolni, mi tör- 
ténik akkor, ha a csatorna zajos, és megsérülnek, esetleg el 
is vesznek egyes keretek. 

Az adó csak azután értesül a sérült keretről, miután sok má- 
sikat továbbított. Egyértelmű, hogy a vevő egy sérült keret- 
tel nem tud mit kezdeni, de mit csináljon azokkal, amelyek 
a sérült keret után érkeztek? Ez azért gond, mert az adat- 
kapcsolati réteg a kereteket csak érkezésük sorrendjében 
adhatja át a hálózati rétegnek. 

Erre a problémára két megoldás is létezik. Az első a vissza- 
lépés n-el (go back n), amikor is a vevő eldob minden olyan 
keretet, amely a sérült keret után érkezett. Mivel nyugtát 
sem küld vissza róluk, az adó ezeket a kereteket is meg fog- 
ja ismételni. 
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4. ábra 1 bites csúszóablakos protokoll, ha mindkét fél egyszerre kezd 
el adni. Ilyenkor duplikátumok lépnek fel. 


Ha belegondolunk, ez a megoldás nem más, mint egy 1 
hosszúságú vételi ablak használata, vagyis a vevő a kerete- 
ket kizárólag sorrendben fogadja el. Addig nem foglalkozik 
a továbbiakkal, amíg az éppen soron következő épségben 
meg nem érkezik. 


Nagyobb átviteli ablak 

A másik módszer értelemszerűen nagyobb méretű átviteli 
ablak használata. Ezt szelektív ismétlésnek (selective repeat) 
nevezzük. 

Ilyenkor a vevő az összes olyan keretet tárolja a memóriában, 
amelyek a hibás keret után érkeztek. Az adónak így csak az 
elveszett vagy megsérült keretet kell megismételnie. Ha az 
újra elküldött keret már rendben megérkezik, akkor a ve- 
vőnek sok-sok hibátlan, ám még nem nyugtázott kerete lesz. 
Ezeket érkezésük sorrendjében át tudja adni a hálózati ré- 
tegnek, majd nyugtázza a legnagyobb sorszámút. Így az 
adó tudni fogja, hogy az ennél a sorszámnál korábbi kere- 
tek hibátlanul célba értek. 

Mindkét módszernek megvan a maga hátránya. Az n-el tör- 
ténő visszalépéses stratégiánál ez nyilvánvaló: ha nagyon 
zajos a csatorna (sok kerethiba lép fel), akkor az a haté- 
konyságból jelentősen visszavesz. 

Az utóbbi módszernél a gond az, hogy minden beérkezett 
keretet tárolni kell a memóriában, egészen addig, amíg az 
adott keretnél korábban fogadottak át nem kerülnek a háló- 
zati réteghez. 

Hogy a két megoldás közül melyiket célszerű használni, az 
attól függ, hogy mi a fontosabb számunkra: a sávszélessé- 
get a lehető legjobban kihasználni, vagy inkább a memóriá- 
val spórolni. 


Magas szintű adatkapcsolat-vezérlés 

Most bemutatunk egy kicsit öreg, ám ma is elterjedt proto- 
kollt, a HDLC-t (High-level Data Link Control — magas szin- 
tű adatkapcsolat vezérlés). Ez egy bit alapú protokoll, 
amelynek a keretezési eljárását sok más protokoll, például 
a PPP is átvette (igaz, néhány kisebb különbséggel). 

A HDLC-t azokban az időkben fejlesztették ki, amikor 

a kommunikációban résztvevő két fél általában egy termi- 
nál és egy ,okos" számítógép volt. 
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A HDLC (és a hozzá hasonló bitalapú protokollok) az 5. áb- 
rán látható keretformátumot használják. Minden keretet 
egy speciális bitsorozat határol, amely a 01111110 (hexadeci- 
málisan 7E). A cím mező olyan kapcsolatoknál érdekes, 
ahol terminál is csatlakozik a vonalra, és valahogy meg kell 
határoznunk, hogy az üzenet melyik terminálnak szól. 

A vezérlés nevű mezőt sorszámozásra, nyugtázásra és 
egyéb hasznos dolgokra használjuk, erről majd egy kicsit 
később. Az adat mező értelemszerűen az átküldendő infor- 
mációt tartalmazza. Ennek nincs meghatározott mérete, 
csupán egy maximuma. Az ellenőrző összeg a hibakeresés- 
re, illetve a hibajavításra szolgál. 

A HDLC olyan csúszóablakos protokoll, amely 3 bites sor- 
számozást használ. Ez azt jelenti, hogy egyszerre 7 nyugtá- 
zatlan keret lehet , kint". 

Háromtéle keret létezik: információs, felügyelő és számo- 
zatlan. Az 5. ábrán láthatjuk e háromféle keret vezérlés me- 
zejének tartamát. Nézzük először az elsőt! A sorszám mező 
a keret sorszáma, az utolsó mező pedig a keretre ültetett 
nyugta. A lekérdezés/utolsó mezőt a HDLC-re épülő proto- 
kollok más és más célra használják. Néhol ezzel lehet a má- 
sik gépet kényszeríteni arra, hogy azonnal küldje a nyugtát, 
és ne várjon addig, amíg azt nem tudja ráültetni egy vissza- 
felé menő keretre. 

A felügyelőkereteket egymástól a felügyelő kód mező alap- 
ján lehet megkülönböztetni. Négyféle felügyelő keret léte- 
zik. Az első típus egy olyan nyugta, amelyet nem lehetett 
ráültetni egy ellenkező irányba menő információs keretre. 
A második típus az úgynevezett negatív nyugta, amely ar- 
ról árulkodik, hogy érkezett ugyan keret, de átviteli hiba 
miatt sérült volt. 

Ilyenkor az adónak újra el kell küldeni az összes keretet 

a ,következő" mezőben lévő sorszámtól kezdődően. 

A harmadik típusú felügyelőkeret a , vételre nem kész". 

Ez ugyan nyugtázza az összes idáig elküldött keretet, 

de utasítja az adót, hogy többet ne küldjön. Ez akkor hasz- 
nos, ha a vevőnek valamiféle átmeneti problémával kell 
megküzdenie, például elfogyott a memóriája a további ke- 
retek tárolásához. 

Az utolsó típus a szelektív elutasítás, amely az adótól csak 
egy bizonyos keret újraküldését kéri. 

Nem szóltunk még a keretek harmadik csoportjától, a szá- 
mozatlan keretekről. Ezek hordozhatnak adatot és vezérlési 
információt is. A különbség az előző kettővel szemben az, 
hogy ezeket a kereteket nem kell nyugtázni. 


Az Internet adatkapcsolati rétege 

Az Internet önnálló gépek sokaságából áll, amelyeket dur- 
ván két részre oszthatunk: hostokra és útválasztókra. 
Ezenkívül az Internethez tartozik még az az infrastruktú- 
ra, amely ezeket a gépeket összeköti. Kis távolságok esetén 
(például egy épület belsejében) általában LAN-okat alkal- 
maznak. Egymástól messze lévő útválasztók azonban úgy- 
nevezett kétpontos összeköttetésben vannak. Ilyen két- 
pontos összeköttetést létesíthetünk például egy bérelt vo- 
nal segítségével. 

Kétpontos összeköttetést nem csak útválasztók összekap- 
csolására használunk. A másik legjellemzőbb felhasználási 
terület az, amikor az egyéni felhasználók otthoni számító- 
gépüket modem segítségével az internetszolgáltatójuk 
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(ISP - Internet Service Provider) útválasztójához kapcsol- 
ják. Ebben az esetben a felhasználó számítógépe egy , teljes 
értékű" host lesz, persze csak addig, amíg a kapcsolat él. 
Legyen szó akár két útválasztóról, amely egy bérelt vonallal 
van összekapcsolva, vagy egy otthoni PC-ről, amely tele- 
fonvonalon keresztül összekapcsolódik az ISP útválasztójá- 
val, minden esetben szükség van valamilyen adatkapcsolati 
protokollra, amely a keretezést végzi. A továbbiakban két az 
internet világában népszerű adatkapcsolati protokollról lesz 
szó: a SLIP-ről és a PPP-ról. 


SLIP (Serial Line IP — Soros Vonali IP) 


Ez egy elég régi protokoll. 1984-ben fejlesztették ki azért, 
hogy munkaállomásokat tudjanak csatlakoztatni az 
ARPANET-hez modem segítségével. A SLIP nem is tud 
semmi egyebet. Nagyon egyszerűen működik. A hálózati 
rétegtől kapott IP csomagokat szépen sorban átküldi, a ke- 
retek végét pedig egy speciális jellel zárja. 

Ha az a speciális jel esetleg előfordul a keretben lévő IP 
csomagban, akkor a régebben bemutatott karakterbeszúrás 
egyik speciális módszerét alkalmazza: a speciális jelzőbájt 
helyett egy másik két bájtos sorozatot küld. Egyes SLIP 
megvalósításokban a keretek is egy speciális bájttal kez- 
dődnek. Az idő előrehaladtával megjelent a SLIP-nek 
olyan változata is, amely megpróbálja a TCP és az IP cso- 
magok fejlécét tömöríteni. Mivel az ilyen csomagok fejlé- 
ceinek sok mezője megegyezik (erről majd később lesz 
részletesen szó), megoldható, hogy a fejlécnek csak egy ré- 
szét küldjük át. 

A SLIP rendkívül népszerű még ma is, sok alkalmazás tá- 
mogatja, ám sosem volt az Internet szabványos protokoll- 
ja. Ezért van az, hogy sokféle, egymással nem teljesen 
kompatíbilis változata létezik. Vannak azonban más súlyo- 
sabb problémák, amelyek miatt a SLIP használata erősen 
behatárolt. 


A SLIP Problémái 


Az első ilyen az, hogy nem tud hibakeresést, illetve hibaja- 
vítást végezni. Ezért a felső rétegekre hárul az a hálátlan 
feladat, hogy ellenőrizzék és kijavítsák a hibákat. 

Ezen kívül a SLIP feltételezi, hogy a kommunikációban 
résztvevő két fél tudja egymás IP címét. Magyarán nincs 
mód a kapcsolat létrejöttekor az IP cím dinamikus módon 
történő meghatározására. 

Ez nem jó hír az otthonról modemmel csatlakozóknak, hi- 
szen nem kaphat minden ügyfél a szolgáltatójától egyedi IP 
címet. Ráadásul még a hitelesítésre sincs mód, tehát az 
egyik fél sosem lehet teljesen biztos abban, hogy valójában 
kivel is beszél. Az utóbbi két dolog persze két útválasztó bé- 
relt vonalas összeköttetésekor nem jelent gondot. Az vi- 
szont már kellemetlen, hogy a SLIP csak az IP alapú hálóza- 
tokkal hajlandó együttműködni. Pedig ma már sokféle , szí- 
nű és szagú" hálózat tartozik az Internethez, és ezek közül 
nem mind épül az IP-re (például a Novell hálózatok is ilye- 
nek voltak, még az 5-ös változat előtt). 


PPP (Point-to-Point Protocol — Pontól — pontig protokoll) 
Mivel a SLIP-pel ennyi probléma volt, sokkal kézenfek- 
vőbbnek tűnt egy olyan új protokoll létrehozása, amely ki- 
küszöböli ezeket a hátrányokat, és ,méltó" arra, hogy 
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5. ábra HDLC protokoll kereteinek felépítése 


internet-szabvánnyá válhasson. Így született hát a PPP 
amely nemcsak képes a hibajelzésre, de többféle hálózatot 
is támogat, és lehetőséget biztosít a dinamikus IP cím hoz- 
zárendelésre, illetve a hitelesítésre is. 

A PPP legfontosabb feladata a keretezés, vagyis az, hogy 

a kereteket egymástól egyértelműen elkülönítse és kijavítsa 
az átviteli hibákból származó sérüléseket. A PPP ezen kívül 
tartalmaz két alprotokollt is. 

Az első az LCP (Link Control Protocol — adatkapcsolat vezér- 
lő protokoll) , amellyel magát a kapcsolatot tudjuk irányíta- 
ni. Ez alatt olyan dolgokat kell érteni, mint például a kap- 
csolat bontása, tesztelése, paraméterek beállítása, stb. A má- 
sik alprotokoll az NCP (Network Control Protocol), amellyel 
a hálózati réteg protokolljának bizonyos beállításait változ- 
tathatjuk meg. Az IP esetében ilyen lehet a dinamikus 
IP-cím hozzárendelése. 


PPP a gyakorlatban 

Hogy a dolog érthetővé váljon, nézzük meg, mi történik, 
amikor otthon modemmel csatlakozunk szolgáltatónk útvá- 
lasztójához. A dolog ott kezd érdekes lenni, amikor a fel- 
használó és a szolgáltató modeme , összesípolt", és létrejön 
a kapcsolat. 

Ilyenkor kezdi meg a munkáját a PPR Először LCP proto- 
koll-csomagok indulnak útnak, amelyek a PPP keretek 
adatmezejében foglalnak helyet. Az LCP segítségével 

a kommunikációban résztvevő két fél megállapodik az al- 
kalmazandó PPP paraméterekben. 

A második lépés a PC-nk hálózati rétegének beállítása. 
Több mint valószínű, hogy TCP/IP protokollkészletet sze- 
retnénk majd használni, ezért szükségünk lesz egy IP cím- 
re. Mivel a szolgáltatóknak általában kevesebb IP címük 
van, mint ügyfelük, ezért bejelentkezéskor dinamikusan 
osztanak ki egyet a felhasználónak. Az aktuális címet az 
NCP protokoll segítségével fogjuk megkapni. 

Nem minden hálózat használ kétpontos összeköttetést. 

A LAN-ok például adatszóró csatornára épülnek. 

A következő részben az ilyen csatornák protokolljaival 
foglalkozunk. 


Garzó András 
garzo(ginterware.hu 














Játékos pingvinek 


Aki játékok futtatására kívánja használni linuxos gépét, 


néhány jó ötletet meríthet Zoltán cikkéből. 


incs más hátra, mint megkoronázni az eddigi mun- 
mh kánkat, és a szórakozást is előtérbe helyezni egy ki- 

csit. A jó munka gyümölcseként, és befejezésként 
építsünk játékgépet linuxos gépünkből. Mégis, mit érdemes 
ilyenkor figyelembe venni? 


Az alkatrészek 


Aki játszani is szeretne a gépén, az szembesül azzal ténnyel, 
hogy korunk játékainak sokkal nagyobb erőforrás igényei 
vannak, mint egy szövegszerkesztőnek, vagy egyéb 
általános programnak. Ez korántsem újdonság, azonban 
Linux esetében nem árt körültekintőnek lenni. Sajnos még 
mindig nem jutottunk el odáig, hogy a gyártók végre figye- 
lembe vegyék azokat is, akik nem csak egy ablakon szeret- 
nek nézelődni. Ez úgy tűnik egy darabig még nem fog vál- 
tozni, legalábbis addig, amíg az adott gyártónak olyan kon- 
kurenciája nem akad, amely esetében már nem mindegy, 
hogy kinél az előny. Ekkor szükséges lesz minden felhasz- 
náló megnyerése, hisz a késhegyre menő harcban mindenki 
számít. Ennek lehettünk tanúi az nVidia vs. Ati, vagy a já- 
ték piacon az ID Software vs. Epic (guake, doom és Unreal 
sorozat) esetében. De addig is, amíg ez bekövetkezik, körül- 
tekintőnek kell lenni. 


Tény, hogy erős gépre lesz szükségünk, de mindez attól is 
függ, hogy mégis milyen játékot szeretnénk futtatni. Ez 
ügyben tudom javasolni a Linuxvilág játék rovatát, ahol 
részletesen megemlítettem a gépigényt is egy adott já- 
téknál. Természetesen minél nagyobb lélegzetű játékkal sze- 
retnénk játszani, annál erősebb gép kell. Ez persze koránt- 
sem jelenti azt, hogy a régi, vagy picike játékok ne vol- 
nának jók. Sőt, olykor jobbak mint az újak. Aki viszont sze- 
retné majd megvenni a cikk írásakor éppen megjelenés 
elött álló Doom 3-at, (ahogy én is) annak tárgytalan a sebes- 
ségre vonatkozó minden adat, és szempont, ugyanis 

a kérdés leegyszerűsödik. Azt vedd, ami jelenleg a legerő- 
sebb. Viszont a helyzet olykor nem ilyen egyszerű. A Linux 
jelenleg még mindig nagyon rosszul áll játékvezérlők tekin- 
tetében. (, hála" a gyártóknak). A botkormányok üzembe 
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helyezése korántsem lehetetlen, de ez csak egyes típusokra 
vonatkozik. Gyakorlatilag kizárólag külső cégek által írt 
meghajtó található meg az interneten, és az sem biztos, 
hogy rendben van. Én például akkor tettem le a botkor- 
mány használatról, amikor kifejezetten egy, a Linux által tá- 
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mogatott típust megvettem. A meghajtó lefordult, de alig 
működött. Sajnos ez könnyen megeshet. Ráadásul alapo- 
sabban kell megnézni a típusát, ugyanis a Linux alatti hasz- 
nálathoz olykor a változatszám, meg SN, és hasonló 
azonosságokat kell keresni. (akárcsak a tévékártyánál és 
webkameránál...) A másik ilyen problémás eszköz 

a gamepad. Szintén nem egyszerű, de valamivel jobbak az 
esélyeink. Természetesen sok extráról le kell mondanunk, 
hisz hiába működik esetleg a gép, ha a ma már alapnak te- 
kinthető programozhatóság nem támogatott. De ugyanez 
érvényes a kormányra, pedálra is, amelyet autós szimuláto- 
rok esetében szoktak beszerezni a játékosok. Az eszköz 
vásárlásakor feltétlenül meg kell nézni, hogy az adott típus 
milyen szinten támogatott — ha ugyan támogatott — Linux 
alatt. Sajnos ha ezt elfelejtjük, rendkívül sok bosszúságot 
szerezhetünk magunknak. Kiemelendő, hogy ez csak a 
különleges eszközökre vonatkozik. A többi, játékhoz szük- 
séges eszközre már nem. 


A jelenleg kapható, a játékosok által leginkább ismert kár- 
tyák már nem jelentenek problémát. Az nVidia remek 
módon támogatja a termékeit, kulturált, és ma már kifor- 
rottnak is tekinthető meghajtói vannak. Az Ati is támogat- 
ja a Linuxot, csak sajnos nem olyan magas szinten, mint 
az nVidia. Kicsit bütykölni kell olykor a meghajtót, hogy 
hajlandó legyen megjeleníteni a 3D-t, ami nem kifejezet- 
ten jó pont. Engem is csak a kiforratlan támogatottság tar- 
tott vissza az Ati-tól, és azt hiszem egy darabig még ez így 
is marad. A többi téren viszont semmi fontosra nem kell 
kitérni, hisz alapértelmezettként is rendben van. Ilyen 

a hangkártya támogatottság. Ma már egy SoundBlaster 
Live Audity, vagy Player, esetleg Live 5.1 szinte alapból 
megy a linux telepítése után, így semmi trükközésre nin- 
csen szükség. Legalábbis a meghajtó szintjén nincsen, 
azonban a szoftveres részben erre még visszatérünk. Tö- 
kéletesen szoktak működni a görgős, optikai, drótnélküli 
egerek billentyűzetek is. Utóbbi esetben a multimédia-bil- 
lentyűk szorulhatnak egy kis bütykölésre. 


A szoftveres feltételek 


A rendszerre telepített meghajtók után lehetőségünk van 
finomhangolni őket. Ennek mikéntjéről a meghajtó leírása 
tájékoztat. Dokumentáció tekintetében a két nagy videó- 
kártya-gyártó közül ismét az nVidia kerül ki győztesen. 
Ugyanis lehetőségünk van letölteni az nVidia honlapjáról 
a leírást, pdf formátumban. Átolvasva rögtön kiderül, hogy 
mennyi lehetőségünk van a kártya beállítása során. PI: le- 
het állítgatni az AGP-hez való viszonyát, skálázni a szín- és 
mintázatértékeket, a kártyára vagy az operációs rendszerre 
bízni az egérmutató megjelenítését, esetleg árnyékolását. 
Rendkívül jó és részletes a leírás, letöltését minden nVidia 
kártyatulajnak javaslom. A másik, amire érdemes odafi- 
gyelni, a GLX. Az nVidia vezérlője a modulok létre- 
hozásakor ezt is elkészíti és telepíti, de ha gyanús, hogy 
esetleg azzal van a gond, célszerű megnézni, hogy engedé- 
lyeztük-e. Igaz ugyan, hogy az UHU-Linux alapértelmezett 
beállítsa az engedélyezett GLX, de érdemes ránézni. Főleg, 
hogy ugyanitt tudjuk skálázni a kártyát. Az útvonal: 
letc/X11/XFé8cconfig 
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Itt az nvidia modult használjuk az nv helyett. Közvetlen 
alatta lehetőségünk van saját beállítást elhelyezni, ha nyi- 
tunk egy sort, option "érték" kezdettel. Az értékeket, a le- 
írás tartalmazza. Természetesen minden beállítás érvénye- 
sítéséhez újra kell indítani az X-kiszolgálót. A hangkár- 
tyánál kicsit más a helyzet. Amit esetleg alapból nem támo- 
gatna Linux, ahhoz lehet, hogy van külső vezérlő. Igaz nem 
túl sok típus ilyen. Ha viszont már támogatott darabunk 
van, akkor gyakorlatilag semmi akadálya a használatának, 
a játékok is rögtön megszólalnak. Egyetlen esetben viszont 
nem: számtalanszor tapasztaltam, hogy a hangok olykor bi- 
zony nem hallhatóak. Sokáig kerestem a bűnöst, míg 
egyszercsak megtaláltam: a KDE alapértelmezett egyik cso- 











magja, a KDE-multimédia tartalmazza az , ArtSD" szervert. 
Egy ez kis hangkiszolgáló, és mixer is egyben, aminek túl 
sok gyakorlati haszna nincsen, kivéve talán, hogy teljesen 
lefoglalja a kártyát, így a legtöbb játék nem is tudja használ- 
ni. És az is meglepő, hogy nem minden kártya esetében for- 
dul ez elő. Az én SB 128 PCI kártyámnál például igen. De 
kollegáim SB live sorozatú kártyájánál ilyen gond nincsen. 

A problémát több módon tudjuk megoldani. Ha ragaszko- 
dunk a KDE használatához, akkor a , KDE vezérlőpult/ 
hang/multimédia/hangszolgáltatás" részben ne engedélyez- 
zük a hangokat. Ezzel sajnos még nincsen minden megold- 
va, mivel a KDE erőlteti a dolgot. A siker érdekében gondo- 
san át kell társítanunk a fájlokat is, hogy mpeg, avi filmek- 
nél, vagy mp3-nál ne a Kabodlee induljon el, ugyanis ő 
rögtön elindítja az artsd-t is. Ekkor külön meg kell ölni sze- 
gényt, ha a film után játszani is szeretnénk. 


A helyigény 


Aki gyakran játszik, ráadásul különböző játékokkal, olykor 
szembesülhet a helyigény kérdéskörével. Talán első látásra 
nem is olyan nagy gond ez, hisz a 80-100-200 GB-os merev- 
lemezek korában élünk, de nem mindenki rendelkezik ek- 
kora tárhellyel. A legtöbb gép alapértelmezettként még 
mindig 20-40 GB hellyel rendelkezik, amin terpeszkedik 

a rendszer, a külső programok, olykor filmek, dokumentu- 
mok. Rutinosabb felhasználók tudják, hogy egy ilyen tár- 
méretű merevlemeznek körülbelül a fele áll majd a játékok 
rendelkezésére. És ha azt hisszük, hogy a 20 GB hely az 
nagy, hát gyorsan meglepetés érhet minket. Én például 
nem szeretem az ilyen kompromisszumokat, hogy mit tö- 
röljek le, ha mást is szeretnék feltenni. Így ha belegondo- 
lunk, hogy a Neverwinter Nights teljes szett 5 CD, 

a Contflict Freespace 2 CD, az összes Unreal együtt az szin- 
tén 5 GB körül van, és ezekhez még nem számoltam hozzá 
a mentéseket, akkor beláthatjuk, szükséges lehet egy másik 
merevlemez üzembe állítása is. Én csak erre a célra raktam 
a gépembe külön 20 GB-ot, amin a játékok terpeszkednek. 
Szerencsére a Linux rugalmassága itt is megmutatkozik. 


Ugyanis a játékok telepítői kizárólag a fő lemezrészt (/) haj- 
landók elfogadni, de a telepítés után szabad a kezünk. Sőt, 
nem egyszer csináltam azt, hogy a telepített játékot becso- 
magoltam, és ha ráfért egy CD lemezre, rögtön ki is írtam. 
Ezek után a megoldás már kézenfekvő. A másik merevle- 
mezre másoljuk föl a játékot, így jó darabig lesz helyünk 
mindenre. Nekem így van elhelyezve közel egy tucat játék. 
Természetesen a fő lemezrészre történő telepítés után is át- 
mozgathatjuk az állományokat, nem szükséges előtte CD-re 
írni. Persze a jövőben jól jöhet. Azt is érdemes szem előtt 
tartani, (főleg maximalistáknak) hogy a merevlemez fizikai 
adottságai miatt lassul a rendszer, ha megpakoljuk azt. En- 
nek egyszerű okai vannak. A merevlemez felépítése miatt, 
ha sok fájl található rajta, megnövekszik az elérési idő, amíg 
megtalálja amit keres. A nagyon tele levő merevlemeznél 
(olyan 6090-os kihasználtság esetén) ez már látható jelen- 
ség, kiváltképp, ha nagyon töredezett. Ezért szokták 
javasolni egy rendszer telepítéséhez, hogy lehetőleg a le- 
mez elejére tegyük, (hisz ott kell a fejnek a legkevesebb utat 
bejárnia), és ha tudjuk kerüljük a nagyszámú kis fájlok 
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használatát. (megfigyelhető, hogy egy 300 MB méretű nagy 
fájlt sokkal gyorsabban fog átmásolni egy másik lemezrész- 
re, mint 1000 jpg fájlt 300 MB értékben.) A kis fájlok 
emellett növelhetik a töredezettséget. 


A játékok minősége 


Sokan hivatkoznak arra, hogy Linux alatt nagyon kevés já- 
ték fut. Valóban sokkal kevesebb, mint amennyit kiadnak 
évente (vagy kiadtak eddig), de a helyzet azért nem ennyi- 
re vészes. A számokra lehet hivatkozni, de mint minden 
számításból ebből is kihagyják az emberi tényezőt. Ugyanis 
amit eddig átültettek Linuxra, azt azért tették, mert roppant 
népszerűek. Illetve szeretnék, ha a linuxos felhasználók 
körében is népszerű lenne. (például az UT200x darabjai, 
amelyek már ,in box" linuxos telepítővel is rendelkeznek.) 
Magyarán a többség kedvenc játéka már fut Linuxon is. 
Körülbelül 30 olyan játék átirata létezik, amely valamilyen 
okból nagy népszerűségre tett szert, illetve többször előke- 
rül a fiókból még manapság is, ha éppen nosztalgiázni tá- 
mad kedve az embernek. És ez a szám folyamatosan nő. 
Tehát már régen nem igaz az a meglátás, hogy aki Linuxon 
szeretne játszani, az valamilyen picike ugrálós, arcade, vagy 
esetleg konzolos programot kellene használnia. A 3D egyre 
jobban működik, és a két legnagyobb játékgyártó (ID, Epic) 
már utat mutatott minden más gyártónak is. (A Bioware 
például már vette a lapot.) A fejlődés tehát most sem állt 
meg, és a jövőben is számíthatunk remek átiratokra, vagy 
külön linuxos fejlesztésekre. 


Következtetés 


Mint a bevezetőben említettem, a Linux még mindig nem 
ideális játékfelület. Azonban már messze nem igaz az, hogy 
olyan rosszul áll a játékok tekintetében. Ha belegondolunk, 
hogy közel 30 játék már rendelkezik natív Linux átirattal, és 
korülbelül 100 garantáltam működik a Wine(X) segítségé- 
vel, az a szókapcsolat, hogy , Linuxos játékgép" már koránt- 
sem nevetséges, sőt kifejezetten valóságszagú. De mint 
mindig, most is a részletekben lakozik a lényeg. A sebesség 
nem csak a processzortól és a memóriától függ, hanem oda 
kell figyelni minden egyes alkatrészre, ahogyan azt már 

a másik rendszer alatt megszokhattuk. A programok beállí- 
tása sem jelent túl nagy problémát, főleg ha belegondolunk, 
hogy a jutalmunk a , linux factor" lesz, amely alapból 5-107 
sebesség növekedést jelent, de könnyedén felugrik 1590-ra 
is, ha jól finomhangoltuk a gépet. Inmáron semmi akadá- 
lya nincsen annak, hogy jó, minőségi játékokkal pihenjünk, 
ha végetért a munka. 


Nincs más dolgunk hát, mint játszani és játszani és várni az 
új Doomra, amely (előzetes hírek szerint) szintén elérhető 
lesz Linuxon is. 


. ] Dancsok , strogg" Zoltán (stroggomail.tvnet.hu) 
Jelenleg technikai szerkesztőként dolgozik a 
BME-OMIKK-nál, ahol oktat is. Emellett egyetemi 
képzésben vesz részt, programozó matematikus sza- 
kon. Négy éve foglalkozik Linuxszal. Szabadidejében 
operációs rendszereket gyűjt és weblapot vezet. 
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A Perl/Tk 


Kölcsönözz felhasználóbarát külsőt a már megírt, hatékonyan működő 


Perl parancsállományaidnak! 


Linuxvilág hűséges olvasói biztosan emlékeznek 
A még arra, amikor saját IRC-botot írtunk, vagy ami- 

kor elkészítettük önálló web pókunkat, hogy azzal 
gyűjtsük be az információkat a világhálóról. Ezeket a fel- 
adatokat azért Perlben oldottuk meg, mert a hálózatkezelés, 
és a vele járó szövegfeldolgozási feladatok ezen a nyelven 
tűnhetnek a legegyszerűbbnek. A Perl különlegesen rugal- 
mas és ennek köszönhetően számos feladatra kitűnően al- 
kalmazható. Biztosan feltűnt, hogy eddigi cikkeimben 
ugyan szó volt szövegfeldolgozásról, könyvtárkezelésről, 
TCP/IP programozásról, de sosem készült valódi felhaszná- 
lói felület programjainkhoz. Csak alapvető be- és kimeneti 
módszereket használtunk, melyekkel parancssorhoz szokott 
szemmel egész jól el lehetett igazodni az alkalmazások 
használatában. Ám mindig gondolni kell arra a felhasználó- 
ra is, aki először ül a monitor előtt, és általában a grafikus 
felhasználói felületekért (GUI) rajong. Képes erre a Perl? 
A válasz természetesen: igen. A Tk-ról van szó, melyet ere- 
detileg a Tcl nevű parancsnyelvhez készítettek el. Később 
azonban egy Perl modul formájában már ebből a nyelvből 
is elérhetővé vált ez a remek eszköztár. Mindenekelőtt sze- 
rezd be ezt a modult a CPAN oldaláról 
(2 http:/www.cpan. org). Több mint valószínű, hogy ter- 
jesztésed is tartalmazza csomag formájában, ekkor elég ezt 
telepítened. Debian alatt a per1-tk csomagra van szüksé- 
ged, amely tartalmaz egy elég jó leírást is. A Tk . pm egy ob- 
jektumközpontú felülettel áll a rendelkezésünkre. Látni 
fogjuk, hogy a grafikus programozás mindössze különféle 
osztályokból történő példányosításokból fog állni. Ha még 
nem barátkoztál meg az objektumközpontú programozás- 
sal, feltétlenül olvasd el a perlboot (1) súgóoldalt, e nélkül 
ugyanis nem fogod tudni alkalmazni az itt bemutatásra ke- 
rülő módszereket. Vágjunk bele! Első lépésként hozzunk 
létre egy ablakot. Íme a kód: 
$1!/usr/bin/per1 -w 


use strict; 
use Tk; 


my $main win - Mainwindow -s new O; 
$main win -5 title ("Hello világ!"); 


MainLoop O; 
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Bemelegítésként nézzük át sorról sorra, mit is csinál ez 

a program. Az első sor mindössze arra szolgál, hogy a pa- 
rancshéjnak meghatározzuk a parancsállományunkat fel- 
neki egy további kapcsolót is, mellyel arra utasítjuk az értel- 
mezőt, hogy a futtatás során a figyelmeztetéseket is jelenít- 
se meg, ne kizárólag a hibaüzeneteket. A következő sor 

a szigorú feldolgozást kapcsolja be. Ha nem tudod, mi ez, 
és jó Perl programot akarsz írni, jobb, ha mindig használod. 
A harmadik sorban pedig a fentebb már emlegetett Tk mo- 
dult vesszük használatba. Ezután létrehozunk egy új skalár 
változót, $main win néven. A my, vagy local kulcsszóval 
történő változóbevezetés szigorú módban kötelező. A két 
kulcsszó a változó láthatóságában tesz különbséget, ám erre 
itt nem térnék ki. Új változónknak azonnal értéket is 
adunk. Jelen esetben a Mainwindow osztály new nevű 
konstruktorát hívjuk meg, mely egy objektummal tér 
vissza. Ezt csak azért hangsúlyoztam, mert Perlben nincs 
megkötés egy osztály konstruktorára vonatkozólag, ezért 
hívhatnák másképp is. Annak, hogy a neve new, megvan vi- 
szont az az előnye, hogy egy már más programozási nyel- 
vekből is ismerős formában is példányosíthatunk: 

my $main win - new Mainwindow; 


Visszatérve a példára, a következő sorban újonnan létre- 
hozott objektumunk egy tagfüggvényét hívjuk meg. 

A title O egy sztringet vár, és segítségével az ablak címét 
módosíthatjuk. Az utolsó sorban történő függvényhívás 
indítja el az eseményciklust. Ez lényegében egy végtelen 
ciklus, amely a különböző vezérlők (widget) eseményeinek 
lekezeléséért felelős. Ne ijedj meg, ha elsőre nem érted, 

a példák világossá fogják tenni ennek a rejtélyes függ- 
vényhívásnak a mibenlétét. A lényeg, hogy az ablak e 
nélkül a sor nélkül nem jelent volna meg. Továbbá az ese- 
ményciklus végtelen tulajdonsága miatt az ablak mindad- 
dig él (és fut a program), amíg az ablakkezelőn keresztül 
be nem zárjuk. 

Miután létrehoztuk első ablakunkat, semmi sem állíthat 
meg bennünket, hogy vezérlőket pakoljuk rá. Íme: 
$1!/usr/bin/per1 -w 


use strict; 
use Tk; 











Gombóc 





Hello 


világ "ENEJEJE 


Hello 





my $main - 
$main -5 title ("Hello"); 


new Mainwindow; 


my $label - $main -5 Label ( 
-text -—5 "Helló világ!", 
-width —s5 25, 
-height -—: 3 

); 


$label -5 pack; 
MainLoop; 


A Tk eszközkészletben számos vezérlő áll rendelkezésünk- 
re. Ilyenek a gomb, jelölőnégyzet, rádiógomb, menü, vá- 
szon, és még sok más. A címke (label) vezérlő egy közönsé- 
ges, a felhasználó által csak olvasható szövegmező. Mint 
minden vezérlőnek, ennek is vannak tulajdonságai. Ezek 
a tulajdonságok már a vezérlő létrehozásakor kaphatnak 
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kezdeti értéket, de vannak alapértelmezett beállítások is. 
Általában igaz, hogy a vezérlőről a Tk: : vezérlő. neve 
(3pm) súgóoldalon kaphatunk egy teljes leírást. 

A hatodik sorban hozzuk létre az új címkét. Látható, hogy 
ehhez mindössze a főablak objektumának a megfelelő 
tagfüggvényét kell meghívnunk, és ez visszaadja az új cím- 
keobjektumot. A Label tagfüggvény egy asszociatív tömböt 
vár paraméterként. Ez egy kulcs-érték párokból álló lista, 
másként fogalmazva egy olyan tömb, ami karakterláncok- 
kal van indexelve. Mi itt egy névtelen tömböt adunk át 

a függvénynek. A kulcsok rendre egy kötőjellel kezdődnek, 
jelezve, hogy beállításokról van szó, ám ezek a kötőjelek bi- 
zonyos Ik változatokban elhagyhatók. Nagyon fontos, 
hogy a kulcsok és értékek között — áll és nem --! 

A következő sor nagyon fontos. E nélkül a címke meg sem 
jelenik az ablakban, hiába hoztuk létre az objektumot. A ve- 
zérlőobjektum ugyanis a létrehozás pillanatában független 
az ablaktól, annak ellenére, hogy a főablak tagfüggvényével 
hívtuk életre. Szükség van egy geometriakezelőre, amely 
felpakolja a vezérlőt az ablakra. Számos geometriakezelő lé- 
tezik, mi most a legegyszerűbbet használjuk, a pack O 
függvényt. Ezt nem szabad összetéveszteni a szabványos 
Perl könyvtárban található pack O függvénnyel. Ez a ve- 
zérlőobjektum tagfüggvénye. Segítségével nagyon egysze- 
rűen, a már meglévő elemekhez képest a négy irányban 
bárhova rakhatunk egy új vezérlőt. Paraméterek nélküli hí- 
váskor folyamatosan egymás alá pakol. 

Nem élet az élet gomb nélkül. Íme: 

1! /usr/bin/per1 -w 


use strict; 
use Tk; 


my $main - new Mainwindow C( 
-borderwidth —- 15 
DE 


$main -s5 title ("Gombóc"); 


$main -s5 Label ( 
-text -—5 "Helló világ!", 
-foreground -—5 "blue", 


-width -—5 30, 
-height — 5 
) -s pack; 


$main -s5 Button ( 
-text —5 "Kilép", 
-width -5 10, 
-height — 2, 
-command -5 Vgexit 
) -s pack; 


MainLoop; 


Számos újdonságot fedezhetünk fel a már megismert ele- 
mek használatában is. Mint láthatod, a főablak objektum 
létrehozásakor is át lehet adni bizonyos paramétereket 

a konstruktornak. Itt az ablak belső szegélyének vastagsá- 
gát adtuk meg képpontokban. Ennek a beállításnak az alap- 
értelmezés szerinti értéke nulla. A félreértések elkerülése 
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végett, ez nem az ablakkezelő által szolgáltatott ablakkeret! 
Ez az a szegély, ami körbeveszi az összes általunk felpakolt 
vezérlőt az ablakban. A címkeobjektumot létrehozzuk, ám 
egy változónak sem adjuk értékül. Ez akkor nem gond, ha 
a programunkban később sehol sem akarunk hivatkozni 
erre a vezérlőre. Ha például később módosítani szeretnénk 
a szöveget, akkor ezzel a könnyelműséggel nem élhetünk. 
Ebben az esetben viszont elég arról gondoskodni, hogy az 
objektum geometriakezelőjét meghívjuk, ezt pedig a fent 
látható módszerrel megtehetjük. Kurta megoldásunknak 
nem látjuk kárát, mert a -- operátor balról jobbra értékelő- 
dik ki. Megadtuk továbbá a címke -foreground beállításá- 
ban a szöveg színét. A gomb létrehozása ezek után már 
gyerekjáték. Itt is egy névtelen gombot hozunk létre, és 
meghívjuk rá a pack O-et. Értelemszerűen a -text a gom- 
bon olvasható szöveget jelenti. Érdekes újdonság a 
-command. Ez egy olyan beállítás, amelynek egy függvény 
címét kell adni. Egy változó címét a N operátorral képezzük, 
a €. pedig a függvénytípust jelöli. A gombra történő kattin- 
tás hatására meghívásra kerül a megadott függvény. 

A MainLoop tehát az ablak kirajzolása után folyamatosan 
vár a gomb megnyomására, és az eseményt kiváltó kattin- 
tást követően meghívja a -command függvényét. 

Jöjjön végre egy igazi példa. 


$1!/usr/bin/per1 -w 


use strict; 
use Tk; 


my $main - new Mainwindow ( 
-title —5 "Hello", 
-borderwidth —5 15 

Jis 


my $framel - $main -5 Frame ( -borderwidth — 
415 


$framel -5 Label ( 
-text —5 "Nevem", 
-width -—s5 10, 
-height —: 1, 
) -:s pack ( -side —5 "left" ); 


my $name; 

$framel -s5 Entry ( 
-textvariable -5 M$name, 
-width —5 20, 
-validate —5 "key", 
-validatecommand -—2 NMgeditentry 
) -3 pack ( -side — "right" ); 


$framel -5 pack; 


my $frame2 - 
S15 0 


$main -5 Frame ( -borderwidth —s 


$frame2 -5 Button ( 
-text -—s "Szia!", 
-width -5 10, 
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-height -—5 2, 
-command —5 Méprinthello 
) -5 pack ( -side -—5 "left" ); 


my $label; 
$frame2 -5 Label ( 
-textvariable -—5 M$label, 
-foreground —5 "blue", 
-width —5 30, 
-height —5 1 
) -5 pack ( -side —5 "right" ); 


$frame2 -5 pack; 


my $guit — $main -5 Button ( 
-text —s "Kilép", 
-width -—s5 10, 
-height —5 1 
) -5 pack; 
$guit -s bind ("-Button-15", sub ( exit; DD; 


MainLoop; 


sub printhello ( 
my $hello - "Szia"; 
if (defined $name and "" ne $name) ( 
$hello .- ", " . $name; 
J 
$hello .- 
$label —- $hello; 


Hg g 
Kg 


sub editentry ( 
$label — ""; 
return 1; 


Az első változtatás az, hogy milyen módon adtuk meg a fő- 
ablak címét. Eddig az objektum title O tagfüggvényét 
használtuk, most áttértünk a kezdetiérték-adásra. A második 
a keretek használata. A keret feladata egységbe foglalni a ve- 
zérlőket. Ez előnyös lehet nekünk, a programozónak, hiszen 
logikai egységekre bonthatjuk a vezérlőelemeket. Előnyös 
lehet a felhasználónak, mert ha láthatóvá tesszük a keret 
szélét, azzal áttekinthetőbbé tesszük a felületet. Továbbá elő- 
nyös lehet a vezérlők elhelyezésekor. Most ez utóbbi miatt 
alkalmazzuk a kereteket, mivel a pack () nem túl okos. Első 
megközelítésben nyugodtan gondolhatsz úgy a keretekre, 
mint kisebb ablakokra a főablakon belül, hiszen nem mások, 
mint vezérlőtárolók. Ez a program egy nevet kér be, majd 
kiírja. Úgy építjük fel az ablakunkat, hogy lesz két keretünk 
egymás alatt, és egy kilépés gomb legalul. A felső keretben 
egymás mellett van egy címke, és egy szövegbeviteli mező. 
A címke természetesen utal arra, hogy mit kell beírni a me- 
zőbe. Az alsó keretben pedig van egy gomb, és egy másik 
címke. A gyomb megnyomására a címkében megjelenik egy 
üdvözlőszöveg, azzal a névvel, amely a felső keretbeli bevi- 
teli mezőben szerepel. Mivel a keret olyasmi, mint egy ki- 
sebb ablak, úgy is kell használni, mint egy ablakot. Létreho- 
zásakor megadhatjuk a keret vastagságát a -borderwidth 











beállítás segítségével csak úgy, mint a főablak esetében. 

A kereten belül elhelyezésre kerülő vezérlőket természete- 
sen a keretobjektum tagfüggvényeivel kell létrehozni. Ezért 
dolgoztunk a fenti példában $frame1, illetve $frame2 objek- 
tumok függvényeivel. Továbbá nem elég az egyes vezérlők- 
re meghívni a pack O függvényt, a vezérlő kipakolása után 
az egész keretre is ugyanúgy meg kell hívni. A következő 
meglepetés egy szövegbeviteli mező formájában érhet. A be- 
viteli vezérlő (entry) egysoros, felhasználó által szerkeszt- 
hető szöveges mező. Hasonló beállításai vannak, mint a cím- 
kének, ám mivel egysoros, nincs -height beállítása. 

A -textvariable által megadható egy változó címe, mely 
mindig a mező pillanatnyi értékét fogja tartalmazni, felülírá- 
sa pedig a mező szerkesztésével egyenértékű. Ám a leírás 
szerint bizonyos esetekben nem javallott írni ezt a változót. 
A -validate segítségével megadható egy, a mező szerkesz- 
tésével kapcsolatos esemény, amely bekövetkezésekor a - 
validatecommand által tárolt függvény meghívásra kerül. Ha 
ez utóbbi függvény igazat ad vissza, a szerkesztés végbe- 
megy, ha hamisat, akkor nem. Ezzel szerkesztés közben kop- 
pinthatunk a felhasználó orrára, ha például egy csak számo- 
kat váró mezőbe betűket pötyögne. Itt csak arra használjuk 
ezt a lehetőséget, hogy töröljük az üdvözlő üzenetet, ha 

a felhasználó szerkeszti a nevet. 

Azt, hogy az alsó keretben szereplő címkénkben mindig 

a helyes üdvözlő üzenet szerepeljen, egy gombhoz rendelt 
függvénnyel oldjuk meg. A függvényünk neve printhel1o 
0. Továbbá használunk egy segédváltozót, melyet a 
-textvariable segítségével hozzárendelünk a címkéhez. 


A címke először nem tartalmaz semmit, hiszen az objektum 
létrehozásakor nem adtunk meg alapértéket. Először akkor 
kaphat értéket, amikor a felhasználó a Szia! feliratú gombra 
kattint. Ekkor meghívásra kerül a printhe11o, amely, miu- 
tán ellenőrizte, hogy a felső beviteli mezőben szerepel-e 
adat, a segédváltozónak értékül adja a megfelelő karakter- 
láncot. A kilépést egy kicsit furcsán oldottam meg. Nem 
használtam a gomb -command beállítását, ehelyett meghív- 
tam a bind O tagfüggvényt. Utóbbi szintén eseményekhez 
rendel függvényeket, ám sokkal általánosabb. Különböző 
egérgombokhoz, egyszeres- és kétszeres kattintáshoz, bil- 
lentyűkombinációkhoz más- és más függvényeket rendel- 
hetünk. Itt az eredmény ugyanaz, mintha a -command-ot 
használtam volna, ám szerettem volna bemutatni, hogyan 
működik a bind O. Első paraméterként meg kell adni az 
eseményt. Ez c jelek közötti egyszerű események sorozata 
is lehet (gondolj az Emacs-ra). A Button-1 a bal egérgomb 
(ezt jelenti az 1-es) egyszeri megnyomását jelenti. Második 
paramétere pedig az a függvény, amelyet az esemény kivál- 
tásakor meg kell hívni. 

Rengeteg dolgot hallgattam el, amiért bocsánatot kérek, 

de sajnos a helyszűke nagy úr. Ajánlom figyelmedbe Steve 
Lidie, Nancy Walsh: Mastering Perl/Tk című könyvét, ami 
egy nagyon jól használható leírás. Az említett súgóoldalak 
pedig töménytelen információval szolgálnak az egyes ob- 
jektum tagfüggvényeinek paraméterezéséről. 


Fülöp Balázs 
admin(oguardware.com 
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Tökéletes főzőfülke 


Rendszerezzük receptjeinket MySOL adatbázis-kiszolgálóval vagy anélkül. 


Izlés szerint. 


emmi különös nincs ebben, mon ami. Egész évben 
S a tökéletes Linux gépről beszélünk, Francois. Egy- 

folytában túl akarjuk szárnyalni magunkat grafika, 
sebesség, memória, lemezterület és egyebek terén. 
A tökéletes persze változatlanul egyúttal a legfrissebb és 
legnagyszerűbb. Az a gondom, Francois, hogy akármennyi- 
re is újak ezek az gépcsodák, voltaképp mind-mind ugyan- 
az. Aztán felötlött bennem, hogy nem segíthetne-e a Linux 
a konyhában, ami végre valami igazán új lenne. 
Nem, Francois, nem kell aggódnod, az állásod nem forog 
veszélyben. Sőt ez pontosan olyasmi, ami a munkádat egy- 
szerűbbé teheti. Tulajdonképpen, nem lennék meglepve, ha 
vendégeink közül sokan úgy éreznék, ha főzés kerül szóba 
Linuxot használni teljességgel természetes dolog. Most, 
hogy a vendégekről beszélek, már látom meg is érkeztek. 
Üdvözlet, mes amis, Chez Marcelnél. Vite, Francois! Szaladj 
a pincébe és hozd fel a 1997-es Brunello di Montalcino-t, 
immédiatement! 
Míg hűséges pincérem felhozza a bort, mesélek egy kicsit 
a mai menüről. A tökéletes géppel foglalkozó értekezéseink 
fénypontjaként felfedeztem néhány programot, melyek gé- 
pünket képessé teszik a főzésre. Nem lefőzésre célzok a tel- 
jesítmény terén, mes amis, hanem főzésre, étellel és borral. 
Miközben keresgéltem a módját, miképpen tudna segíteni 
a Linux a konyhában, ráakadtam a Krecipes programra 
(lásd a hálózati forrásokat!). Unai Garro, Jason Kivlighn és 
Bosselut Cyril nagyon szép nyílt forrású csomagot rakott 
össze amely gyerekjátékká egyszerűsíti saját receptjeink 
elkészítését és karbantartását. A Krecipes segítségével el- 
készíthetjük saját receptjeinket illetve beolvashatjuk 
őket a legnépszerűbb csereformátumukból (RecipeML, 
MasterCook, Meal-Master és egyebek). Saját receptjeinket 
KreML (Krecipes XML formátum) formátumban menti el. 
Karbantarthatunk kategóriákat, nyomon követhetjük a ka- 
lóriákat (rost, zsír és egyéb összetevőket), vásárlási listát ké- 
szíthetünk a kiválasztott étkek alapján. 


Ah, Francois, hát visszatértél. Kérlek, tölts a vendégeinknek. 


A Krecipes adatbázisban tárolja a recepteket, ezért a prog- 
ram lefordítása és használata előtt fel kell telepítenünk 

a MYySOL vagy az SOLite (lásd a forrásokat ) programot. 
Az SOLite apró, programba ágyazható adatbázismotor ami- 
hez kevesebb kezelési és karbantartási többletmunka kell 
mint a MySOL-hez, viszont nem olyan teljesértékű és haté- 
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1. ábra Marcel híres Spanyol Omlettjének leírását gépeli 
be a Krecipes segítségével 


kony. Az ilyesfajta alkalmazásokhoz viszont sokan vonzó 
lehetőségnek találhatják. Az a szép az SOLite-ban, hogy 
nincs szükség adatbázis-kiszolgáló futtatására a rendszeren, 
mégis kihasználhatjuk az SOL adatbázis-tárolási és elérési 
képességeit. 

Amennyiben MySOL és SOLite is van gépünkön, fordítás- 
kor mindkét rendszer támogatása bekerül a programba. 

A fordításról csak annyit, hogy klasszikus példája a szoká- 
sos öt lépéses fordítási folyamatnak: 


tar -xzvf krecipes alpha 0.4.1.tar.gz 
cd krecipes 

. /configure --prefix-/usr 

make 
su -c "make install" 

Először a Krecipes varázslóval találkozunk (a program neve 
egyébként krecipes), amely végigvezet bennünket néhány 
alap beállítási lehetőségen, többek közt, hogy melyik adat- 
bázisban szeretnénk tárolni az adatokat. Amennyiben 
MYSOL és SOLite támogatást is fordítottunk a programba, 
bármelyiket választhatjuk. Minthogy éttermünkben már 











rengeteg MySOL hátterű programról szó esett már, úgy 
gondoltam nem rossz ötlet kipróbálni a SOLite-ot. Válasz- 
tottam majd a Next-re kattintottam. 

Miután választottunk, a Krecipes felajánlja a lehetőséget, 
hogy az adatbázist feltöltse néhány példarecepttel. Ne 
felejtsük el bejelölni ezt a négyzetet a beállításoknál, így 
lesz néhány mintánk ami segít megismerkedni a program 
képességeivel. 

Új recept létrehozásához kattintsunk a File pontra menü- 
ben és válasszuk a New-t avagy egyszerűen kattintsunk 
a new recipe gombra az ikonsor bal felső sarkában. A re- 
cept űrlapjának három füle van. Az első a recept alapada- 
tait írja le — a nevet, a szerzőt, melyik kategóriába sorol- 
juk az étket (új kategóriákat is készíthetünk), illetve hány 
emberre szól a recept. Erre az 1. ábrán láthatunk példát. 
A másik két fül az összetevők és a leírás számára van 
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2. ábra Egy kis Huevos Rancheros tálalása 
a LargoRecipes segítségével 


fenntartva. Minden esetben bármikor elmenthetjük 

a munkánkat vagy később visszatérhetünk ha frissíteni 
szeretnénk valamit. 

Amennyiben inkább az Interneten Meal-Master és 
RecipeML formátumban megtalálható több ezer receptből 
szeretnénk válogatni, nagyon könnyen importálhatjuk 
őket. Ez a sok beszéd az étkekről, mes amis, csak azt bizo- 
nyítja mennyire fontos is egy jól feltöltött borospince. 

A másik nagyszerű receptkezelő amit érdemes megvizs- 
gálni, Douglas Sguirrel LargoRecipes programja. 

A LargoRecipes segítségével (amely egyébként a szerző ku- 
tyája után kapta nevét) receptjeinket kezelhetjük, megoszt- 
hatjuk őket barátainkkal (weblapokon keresztül), készíthe- 
tünk vásárlási listákat, készíthetünk étkezési tervet és így 
tovább. Itt is importálhatunk Meal-Master és RecipeML 
formátumú recepteket. A 2. ábrán működés közben is meg- 
tekinthetjük a LargoRecipes-t. 

A LargoRecipes telepítéséhez legalább 1.4-es Javára lesz 
szükségünk, amiből kikövetkeztethetjük, hogy fordításra 
viszont ez esetben nem lesz szükségünk. Két fájlt kell letöl- 
tenünk és elmentenünk a LargoRecipes weblapról (lásd 

a forrásokat). Az első a largorecipes terjesztés, hamarosan 
rátérek a második állományra is. Az írás születésekor 

a 0.9.2.1-es változat volt a legfrissebb. A csomag telepítésé- 
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hez mentsük el a csomagot tetszőleges helyre - én egy 
Largo könyvtárat készítettem a felhasználói könyvtá- 
ramban -— majd hajtsuk végre a következő parancsokat: 


cd -/Largo 
java -jar largorecipes-0.9.2.1.jar 


További használatkor is ezeket a parancsokat kell majd kiad- 
nunk. Első futáskor a telepítési ablak jelenik meg. Az összes 
szükséges adatfájl és könyvtár ott jön létre ahol elindítottuk 
a telepítést. Az egyik ilyen könyvtár neve demo. Ide kell el- 
mentenünk a letöltött második állományt, a LargoRecipes 
demo fájlt. Ezt is letölthetjük a LargoRecipes weboldal letöl- 
tési lapjáról. 

Amennyiben a futás során szeretnénk kipróbálni a példare- 
cepteket, kattintsunk a LargoRecipes pontra a menüsoron 
majd válasszuk a Demonstration pontot. Ha ezt inkább át- 
ugornánk, és egyből el akarjuk kezdeni bevinni a recepteket, 
kikapcsolhatjuk a LargoRecipes RecipeML archive négyzetét. 
A honlapon 10,000 receptet találunk összezippelve; a hivat- 
kozást a főlapon találjuk. 

Aki szeretné másokkal megosztani receptjeit, a Largo- 
Recipes programban weboldal-exportáló pontot is talál. 
Kattintsunk a menüsor Internet gombjára és válasszuk 

a Web Page pontot. Az elérhető receptek listája máris meg- 
jelenik a a jobb oldali ablakban. Válasszuk ki szimpatikusa- 
kat majd az Add segítségével vegyük fel az export listára. 
Ha mindent kiválasztottunk, adjunk címet a lapunknak, de 
még ne kattintsunk a Go-ra! Látnunk kell itt egy Include 
XML Download feliratú jelölőnégyzetet. Ezt ne felejtsük el 
bekapcsolni, az összes receptlapunkon, így a látogatók 
RecipeML formátumban letölthetik majd a receptjeinket és 
kedvenc receptkezelő rendszerükbe importálhatják. 

Aki igazán kíváncsi, a források részben megtalálja 

a RecipeML formátum leírás hivatkozását. Soha sem árt ha 
az ember tudja, hogyan működnek a dolgok, non? Beírtam 
egy hivatkozást a Meal-Master weboldalra is. Rengeteg hi- 
vatkozást találunk itt, ezeket követve pedig rengeteg recep- 
tet találhatunk melyek mind készek rá, hogy a kedvenc re- 
ceptgyűjtőnkbe importáljuk őket. 

Mon Dieu, mes amis, elérkezett a záróra és én csak tovább 
éheztettem önöket. Francois talán lesz olyan kedves és új- 
ratölti a poharainkat még egyszer. Addig én kihozom a hí- 
res dupla vajas briósomat fűszeres, vegyes- bogyós lekvár- 
ral. Most hogy ennyi kísértő finomsággal tömtük meg 
linuxos rendszerünket, az előételek bizony elsőbbséget él- 
veznek. Következő találkozásunkig, mes amis, igyunk egy- 
más egészségére! 


A vötre santé! 
Bon appétit! 


Linux Journal 2004. augusztus, 124. szám 


Marcel Gagné (mggagnesalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában megjelent 
Válts Linuxra! — búcsú a kékhaláltól 

(ISBN 963 9301 76 0) című könyvnek. 
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Egy igazi örökzöld: Fallout 


Talán mindenki emlékszik a nagy klasszikusra, a Falloutra. Anno, mikor megjelent, 
stílust teremtett, és grafikája — ha nem is volt a kor csúcsa -, nem hagyott kíván- 
nivalót maga után. Játékmenete, stílusa pedig garantálta, hogy egykönnyen ne 
lehessen végigjátszani, Így semmiképpen sem eshetett korunk (sajnos) általános 


eldobod úgyis, csak vedd meg tölünk" kategóriájába. 


játék a régi motorosok 
számára jól ismert, talán 
csak az újabb játékosgenerá- 


ciónak jelent újdonságot. Maga 

a program alapműnek számít min- 
den játékos, és azon belül is a szerep- 
játékosok számára. Mondhatnám, 
kötelező darab. 

Nem csoda hát, ha felcsillant a sze- 
mem, amikor megláttam, hogy életre 
kelthető Linux alatt is. Így hát semmi 
sem tarthatott vissza attól, hogy le- 
töltsem a telepítőt, és nosztalgiázzam 
kicsit. 

Azokról az időkről, amikor még 

a játékot a játék adta el, és nem 

a marketing, amikor még nem vol- 
tak másolásvédelmek, és nem fenye- 
gettek meg nyíltan tizenéves gyere- 
keket a gyártók. 

A hőskor kiemelkedő darabjával van 
hát dolgunk. 


A játékmenet 

A játékmenet és a történet jól ismert, 
de fussuk át kicsit, hátha valaki nem 
ismeri még a programot. A történet 
az emberi civilizáció pusztulása 

után játszódik, ahol kis elszigetelt 
csoportok élnek elzárva a föld alatti 
erődítményekben. Ebben a világban 
élet-halál harc folyik mindenért, ami 
elősegítheti az életben maradást, 
vagy a közösségek fenntartását. Ilyen 
a lőszer, a fegyver, a gyógyszerek és 
az üzemanyag. 

Hősünk kénytelen elindulni a hosszú 
útra, ki, a sugárfertőzött, pokoli 
világba, ahol banditák, mutánsok, és 
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mindenféle szörnyeteg les rá. Termé- 
szetesen mindezt gyengén felfegy- 
verezve, rendkívül alacsony szinten 
teszi. Az egyik cél a küldetés teljesí- 
tése, a másik viszont határozottan 

az életben maradás. 


Ez ugyanis szintén nem egyszerű 
feladat, igaz, nem is bosszantóan 
nehéz a játék. 

A játékmenet viszont korántsem egy- 
hangú, és nem is válik azzá, ellentét- 
ben az Unreal-lel. A harcrendszer 
ugyan kicsit egyszerűre, de érdekesre 
sikeredett. 

A játékban megtalálható szerepjáték- 
elemek azonban manapság már ko- 
rántsem korszerűek. Amikor ugyanis 
a játék készült, még nem létezett 

a Dé-D3 rendszere, többek között ez 





a program is nagymértékben hozzájá- 
rult ahhoz, hogy manapság ilyesmik 
létezhessenek. Inkább a hangulat az, 
ami vissza-visszavonzza a játékost 

a jövő eme senkiföldjére, hogy újra, 
és újra küzdhessen a túlélésért. 

Ez a hangulat viszont tökéletes. 

A készítők rendkívül jól eltalálták 

a határt, hogy mennyire legyen az 
atmoszféra komor és félelmetes, de 
ne csüggesztő. 

Főleg, hogy az alaphangot egy kiváló 
intro adja meg, amelyet, úgy gondo- 
lom, nem ártana egy-két politikusnak 
is megnéznie, hátha elgondolkodna 
az emberiség jövőjét illetően. 

A feketehumor is lépten-nyomon 
visszaköszön, így garantált, hogy 
sosem unatkozunk. 


Hangok, grafika, gépigény 

A program kiadásakor még nem volt 
nagyon elterjedt a 3D megjelenítés, 
főleg ebben a műfajban. A 3D először 
az FPS-ben kezdett hódítani és lett 

a Ouake után de facto szabványmegje- 
lenítés. Sok időnek kellett azonban 
eltelnie ahhoz, hogy ez elterjedjen, 

és megvesse a lábát a stratégiai és az 
RPG játékokban. Ezért a Fallout nem 
is használ 3D-t, így egy régebbi, 

3D kártya nélküli gépen is remekül 
futtatható. 

Korának és az akkori technológiának 
köszönhetően a gépigény sem magas. 
Az én Duron 800 Mhz-es gépemen 

a WineX ellenére egy pillanatnyit sem 
zökkent, tökéletesen futott. A pro- 
cesszor az, ami fontos. Mindez talán 
köszönhető annak is, hogy program 
szempontjából is alapos munkát vé- 
geztek a készítők, így minimális az 
ilyen hibák száma. 

Mindezt azért említem meg, mert 
érthetetlen számomra, hogy komoly 
világcégek hogy nem képesek úgy 
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megcsinálni egy programot, hogy he- 
lyenként ne akadjon, vagy az intro 

ne szaggasson be. 

Az ok biztosan nem a gépigényben 
keresendő, hisz olykor több éves 
játékoknál látható, egy mai, korszerű 
vason. 

A grafika tehát nem 3D, ennek elle- 
nére tetszetős. Teljesen átlátható 

a játéktér, nincsenek zavaró elemek, 
és egy óra játék után a kezelhetőség 
is teljesen a helyére billen (igaz, 

hogy addig viszont minden baja van 
a játékosnak). 

A hangulatot fokozó hangok viszont 
annál érdekesebbek. Teljesen , lefedik" 
a játékot. A zene kellemes, és olykor 
határozottan adrenalinemelő, a han- 
gok mai füllel már kicsit porosnak 
hatnak, de ettől függetlenül teljesen 
rendben vannak. 

Kiemelendő itt, hogy ez a játék kerüli 
az élesebb hangokat, így sosem ijeszti 
meg a játékost, és hosszú játék után 
sem lesz kellemetlen hallgatni. 
(Bizony előfordul, hogy egy-két játék- 
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ban olyan hangot adnak a snipernek, 
ami mindössze egy elviselhetetlen 
éles csattanásból áll. Tíz lövés után 
megpróbáltam meglenni nélküle.) 


A telepítés 

Ez a játék is, mint (sajnos) annyi má- 
sik, csak emulátorral hajlandó futni. 
Így a Fallout is csak WineX-el indul, 
ennek megléte tehát kötelező. 

A WineX elérhető 

a 5 http:/www.transgaming.com 
oldalon. 

Ha ez megvan, akkor semmi akadálya, 
hogy telepítsük a programot. Ehhez 
kell a telepítő, 

(2 http:/iflg.sourceforge.net/), és 

a gyári CD lemez. Figyelem, ez a te- 
lepítő is egy összedrótozott WineX-es 
bináris, amelyet a loki által fejlesztett 
game installer motor rak fel a gépre. 
Így az automount probléma továbbra 
is fennállhat (azért kell kikapcsolni, 
mert egyébként nem látja a CD-t). 
Természetesen rendszergazdaként 
hajtsuk végre a telepítést. Ha ez is 
megvan, akkor gyakorlatilag semmi 
akadálya sincsen a játéknak. Mint 

a DeusEx esetében tapasztalhattuk, 

a fejlesztők kiváló munkát végeztek. 
Egy telepített teljes értékű WineX 
megléte esetén, gyakorlatilag azonnal 
futásra kész a telepített játék, minden- 
féle beállítás nélkül. Aki a WineX-szel 
már próbálkozott, az tudja, hogy 

ez nagy szó.) 

Ezért a telepítést merem kezdőknek 
is ajánlani, hisz a játék problémamen- 
tesen felkerül a lemezre, és fut. 

Most már mindnyájan élvezhetjük 

a Fallout komor, kemény, de csodá- 
latos világát, és bekalandozhatjuk 
Linuxon is ezt a világot. 
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További kellemes játékot kívánok 
ezzel az örök klasszikussal. A követke- 
ző hónapban egy igazi csemegét 
veszünk szemügyre, a Jedi knightII: 
Jedi Outcast-ot. 


Dancsok , strogg" Zoltán 
(stroggomail.tvnet.hu) 
Jelenleg technikai szer- 
kesztőként dolgozik a 
BME-OMIKK-nál, ahol oktat 
is. Emellett egyetemi 
képzésben vesz részt, programozó matema- 
tikus szakon. Négy éve foglalkozik Linuxszal. 
Szabadidejében operációs rendszereket 
gyűjt és weblapot vezet. 
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Szoftverjog - barát vagy ellenség? 


Bevezető gondolatok egy szoftverjogi sorozathoz. 


lapvetően három magatartásforma létezik, mellyel 
A egy jogász jelenlétét egy informatikusokból álló 
társaság képes lereagálni: 

e utálják 

" tartanak tőle 

" kíváncsiak rá 
Az első kategóriába tartozókat arra kérem, hogy azonnal 
lapozzanak tovább és pár nap múlva érdeklődjenek egy 
olyan barátjuknál, aki a két másik csoport egyikébe tartozik, 
hogy miről is szólt ez a cikk. Azokat, akik fenntartásokkal 
közelítenek minden doktorhoz - legyen az jogász vagy 
fogorvos — szeretném megnyugtatni, hogy a cikksorozat 
megírása során tisztán jószándék vezet. Legfőbb célom 
hogy a számítástechnika iránt érdeklődőket (kezdőket és 
profikat egyaránt), kicsit közelebb vigyem a jog világához, 
annak egy érdekes és mindenki számára érthető oldalát 
bemutatva. Mellesleg a fogorvosokkal én sem vagyok 
teljes mértékben kibékülve. 
A kíváncsiakat arra bátorítom, hogy küldjenek e-mailt, 
kérdezzenek, írják meg, hogy miről szeretnének olvasni. 
Ígérem, hogy a sorozat összeállítása során figyelembe 
fogom venni ezeket a javaslatokat. 


Tervek 

A szoftver keletkezésének nemcsak gyakorlati, hanem jogi 
szempontból is különböző állomásai vannak. Ezért első 
körben a szoftver fogalmával kell tisztába jönnünk. Ezt 
követően szó esik majd az alkotásról magáról, arról hogy 
kik és milyen feltételekkel minősülhetnek szerzőnek, illetve 
hogy a szerzőket milyen védelem illeti meg. 

Kiderül majd, hogy munkaviszonyban illetve azon kívül 
alkotott programok esetében milyen jogvédő eszközök állnak 
rendelkezésünkre. Kitartó olvasóink megtudhatják, hogy mi 
az a felhasználási szerződés és miért hívja a jogászokon kívül 
mindenki más ezt , licencnek". Ezek után teszünk egy rövid 
körutazást, melyben megismerkedhetünk ezen szerződések 
alaptípusainak jogi hátterével. 

Reményeim szerint kitérünk majd arra is, hogy webes 
felületen milyen feltételek mellett lehet — akár értékesítési, 
akár más célból - szoftvereket közzétenni. 


A szoftver(jog) tárgya 

Egyesek szerint a szoftverjog, mint olyan, nem is létezik, 
hiszen sehol nincs egy önálló jogi kódex, amelyben 
minden, a szoftverekkel kapcsolatos jogi szabályozás 
megjelenne. Ráadásul rengeteg olyan jogterület van, 
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melyeket a szoftverekre — azok egyedi megjelenési tulaj- 
donságai miatt — nehéz alkalmazni. 
Mások szerint a szoftverekben semmi különleges nincs, 
semmi olyan, ami miatt külön említést érdemelnének. 
Én személy szerint úgy gondolom, hogy a bennünket 
körülvevő , digitális világ" élő és egyre fejlődő terület, mely 
nyilvánvalóan fontos részét fogja képezni a jövőnknek. 
Elég, ha csak az elektronikus kereskedelemre gondolunk. 
Ennek tulajdonképpen a háttérben működő szoftver 
a lelke, ahogy az egész virtuális világnak is. A terület külön- 
leges voltát pedig, úgy érzem, ezen a fórumon egyáltalán 
nem kell bizonygatnom. 
Az, hogy a szoftverjog tárgya maga a szoftver — evidencia. 
Az viszont, hogy mi maga a szoftver, már rázósabb kérdés. 
Vegyük például a szoftver meghatározását. Mikor műszaki 
könyvekben kerestem e fogalom leírását, mintegy 15 külön- 
böző műben 15 eltérő változatot találtam. Ezek után talán 
nem meglepő, hogy a jogászok is meglehetősen bonyo- 
lultan látják a kérdést. 
A jog számára elsődlegesen természetesen a jogszabályban, 
jelen esetben a szerzői jogról szóló 1999. évi LXXVI. 
törvényben rögzített meghatározás az irányadó. 
Eszerint szerzői jogi védelmet élvez ,a számítógépi prog- 
ramalkotás és a hozzá tartozó dokumentáció (a továb- 
biakban: szoftver) akár forráskódban, akár tárgykódban 
vagy bármilyen más formában rögzített minden fajtája, ide- 
értve a felhasználói programot és az operációs rendszert is." 
Mosolyogva vehetünk egy nagy levegőt, hiszen legalább 
már van mibe kapaszkodni, aztán persze lelkesedésünk 
alábbhagy, mikor felötlik bennünk, hogy nem ártana 
pontosan meghatározni, mi is az a számítógépi 
programalkotás", illetve a , hozzá tartozó dokumentáció" . 
A fenti sorokat boncolgatva rájöhetünk, hogy a jogászok 
tulajdonképpen a következő három csoportba próbálják 
besorolni a szoftvereket: 

1, az operációs rendszerek, 

2, a felhasználói programok, 

3, az egyéb (ide tartozhatnak például a kiszolgálóoldali 

alkalmazások) 
Az azért egyértelműen kitűnik a felsorolásból, hogy a véde- 
lem mindent átfog. Azaz majdnem mindent. 
Valamely ötlet, elv, elgondolás, eljárás, működési módszer 
vagy matematikai művelet nem lehet tárgya a szerzői jogi 
védelemnek (akkor sem, ha csatolófelület — informatikusul 
interfész — alapját képezi). A védelem további feltétele még 
az egyéni, eredeti jelleg. De ha ez az egyéni, eredeti jelleg 





már a szoftver félkész állapotában is kirajzolódik, a véde- 
lem értelemszerűen e pillanattól kezdve megilleti a művet. 
Ehhez nincsen szükség semmiféle külön jogi hókuszpó- 
kuszra, nincs bejelentési kötelezettség, nem kell lajstrom- 
számot kérri, a szerzőt megilleti a védelem, egyszerűen 
azért, mert szerző. 

Ha tehát az Olvasó legközelebb kitalál néhány sort egy 
újságcikkhez vagy éppen egy program forráskódjához, 
majd le is írja, vagy bármilyen egyéb módon dokumen- 
táljajuk azt, akkor kérem, dőljön hátra egy kicsit és jóleső 
érzéssel a lelkében mélázzon el azon, hogy most szerzővé 
vált és az alkotása jogilag védett. 

Persze azért nem árt a dolgot egy-két példányban lemá- 
solni, és jól eltenni, mert a jog csak szerzői jogi jogsértések 
ellen véd, az áramszünet vagy merevlemez meghibásodása 
ellen nem. Ha ilyen módon veszik el szellemi alkotásunk, 
az bizony a mi hibánk. 


Most, hogy már tudjuk, hogy minden sornyi programunk 


védett, áttérhetünk egy másik érdekes kérdésre. Tegyük fel, 


hogy reggeli közben - jobb épp nem lévén - a kezünk 
ügyébe eső sajtpapírra vetjük a kávé és a pirítós közötti 
villanásnyi szünetben kiötlött világmegváltó gondola- 
tunkat, mondjuk műszaki szervezési ismeretek témakör- 
ben. Védett vagy sem ez az alkotás? 

Ilyen esetekben elsődlegesen mindig azt kell eldönteni, 
hogy mekkora darab sajtpapírunk volt és vajon az általunk 


4 a! 


leírtak meghaladják-e az , ötlet, elv, elgondolás" szintjét. 


Látogasson el hozzánk! 








A szerzői jog keze ugyanis az említett területekre már nem 
ér el. Ilyenkor ugyanakkor segítségünkre lehet a Polgári 
Törvénykönyv, amely az alábbi módon rendeli védeni 

a sajtpapírokat: 86.§ (4) A személyeket védelem illeti meg 
a vagyoni értékű gazdasági, műszaki és szervezési 
ismereteik és tapasztalataik tekintetében is. A védelmi idő 
kezdetét és tartamát jogszabály határozza meg. 
Leszögezhetjük azt is, hogy a védelem nem függvénye 

a terjedelemnek. A szerzői jog ugyanúgy védi Pilinszky 
Négysorosát, mint Heller Huszonkettes csapdáját. 
Nincsenek esztétikai követelmények sem, vagyis az 
egyetemi feladatként összetákolt elégségessel jutalmazott 
kódunk ugyanúgy védett, mint azé az embertársunké, aki 
csodálatos módon jelest kapott. Persze ha arról van szó, 
hogy két különböző tanárhoz kell beadnunk a feladatunkat, 
s bár azokra ugyanúgy jelest kapunk, mint fent említett 
embertársunk, ám már egy merőben felületes 
összehasonlítással is megállapítható, hogy a két mű közötti 
egyetlen lényeges eltérés a beadó neve, akkor nem szerzői 
alkotásról, hanem bitorlásról beszélünk, melyet a törvény 
büntet(het). Ez azonban már egy másik történet. 


Dr. Dudás Ágnes (dudas.agnesoabend.hu) 
ügyvédjelölt, az FSF egyik aktivistája. 2004-ben 
végzett az ELTE Jogtudományi Karán. Szakdol- 
gozatát a szoftverek szerzői jogi védelméről 
írta, a 2003-as évet pedig e terület kutatásával 
a berlini Humboldt Egyetemen töltötte. 


Virtuális könyvesboltunk egyedülálló választékot kínál 
magyar és angol nyelvű számítástechnikai könyvekből. 


saját címjegyzéket tárolhat, segítségével 


vásárláskor egy gombnyomással kítöltheti 


ha megtetszett egy könyv, 
de csak később szeretné megrendelni, 
felteheti virtuális könyvespolcára, ahol 
mi megőrizzük. 


! j Számítástechnikai 
KISKMLPU zdsáztotas sak Jas 


a kívánt postázási adatokat. 
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A System Rescue CD 


A Kedves olvasókkal most egy nagyon kellemes Linux darabot szeretnék megis- 
mertetni, ez pedig nem más mint a System Rescue CD. Ahogyan a neve is mu- 
tatja, nem kifejezetten otthoni vagy irodai használatra szánt Linuxról van szó, 

és a későbbiekben kiderül az is, hogy nem is csupán Linuxról. 


gy CD-ről lesz szó, amit többféle céllal is lehet hasz- 
E nálni. Egyik nagy előnye, hogy a hivatalos változat 
mindössze 102MB, amit ezért bárhová könnyen ma- 
gunkkal cipelhetünk. Eltehetjük akár az irattárcánkba is, és 
ha éppen unatkozunk, máris kéznél van egy kellemes 
Linuxos környezet. Annak idején kíváncsiságból kezdtem 
foglalkozni a System Rescue CD-vel, de lassan 
megkedveltem és rájöttem, hogy egy nagyon hasznos se- 
gédeszközt tudhatok a kezemben; azóta sehová sem indu- 
lok el nélküle. Mindezek mellett a rendszer alapvetően 
rendszergazdai feladatok ellátására készült. Ennek megfele- 
lően rengeteg hasznos segédprogramot tartalmaz, melyek- 
ből itt láthatunk egy összefoglalót: 
e Linux rendszermag: v2.4.24 
e  Framebuffer-támogatás, nincs szükség az XWindow 
rendszerre 
e  OTParted - grafikus lemezfelosztó program 
e — parted — a klasszikus GNU lemezfelosztó program 
e — partimage - biztonsági mentésre 
e dump és restore - a klasszikus biztonsági mentésre al- 
kalmas programok 
e — sfídisk — felosztásitábla-kezelő program 
e  dar — tömörítőprogram (a tar-hoz hasonló) 
e . clam AntiVirus 
e . Midnight Commander 
e  szövegszerkesztők : vim, nano, OTinyEditor 
e . Samba, NES és SSH támogatás 
e  Links szöveges böngésző 


A fenti lista alapján bárki azt mondhatná, hogy ,ide vele de 
hamarost!" , tehát máris indulhat a vadászat, amihez jó kiin- 


dulási alapot jelenthet a 5 http:/www.sysresccd.org honlap. 


Nézzünk egy kicsit a dolyok mélyére 

Amikor a CD elindul, rengeteg beállítási lehetőségünk van. 
Többféle segédprogram közül választhatunk és nem csak 

a Linuxot indíthatjuk el róla, de a hardverfelismerő- és in- 
formációs programot, az aidát is. A lemezen lévő FreeDOS 
változat alapjában véve alkalmas lemezfelosztásra (a DOS- 
os fdisk található meg benne) és FAT fájlrendszer formá- 
zására. Aki nem ismerné az aida programot, röviden annyit 
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elég tudni róla, hogy 45 képernyőn keresztül a számítógé- 
pünk minden egységéről, részletes információkat kapha- 
tunk. A ranish lemezrészkezelő program is hasznos. Ugyan 
alapvetően csak a FAT16 és FAT32 típusú lemezrészeket 
képes kezelni, de van két említésre méltó tulajdonsága. 

Az egyik, hogy teljes merevlemezekről képes másolatot 
készíteni, a másik pedig, hogy felületi ellenőrzést végezhe- 
tünk a segítségével a megadott lemezrészen. A lemez tartal- 
maz még egy rendszerbetöltő-kezelő programot (boot- 
manager), egy memória ellenőrzőt (memtest) és egy segéd- 
programot, amivel az adatainkat véglegesen letörölhetjük 

a lemezekről. A fentebb említett programokat a CD elindulá- 
sa után indíthatjuk a megfelelő lenyomat (image) kiválasztá- 
sával. Az induláskor egy szokásos LILO parancssort kapunk, 
ahol az aida, a ranish vagy a freedos beírásával indíthatjuk 
el a kívánt programot. Térjünk rá végül a CD lényegére, 

a Gentoo alapú Linuxra. Mint ahogyan eddig is, a megfelelő 
lenyomat nevének beírásával indíthatjuk el a rendszert, ám 
a választék igen bőséges. A rendszert indíthatjuk kép-puffer 
támogatás nélkül, a nofb lenyomatot indítva, vagy 800x600 
és 1024x768 képpontos felbontásban a fb800 és a fb1024 
segítségével. Külön lenyomat betöltésére van szükség, ha 
Intel810-alapú videovezérlővel rendelkezünk (i 810fb640, 
i810fb800 és 1810fb1024 néven érhetők el). 


Indítsuk el 

A megfelelő rendszermag kiválasztása után további para- 
métereket adhatunk meg az indításkor. Az első ilyen fonto- 
sabb paraméter, a cdcache, amellyel rávehetjük az induló 
rendszert, hogy a teljes CD tartalmát töltse be a memóriába. 
Ezután a CD-ROM meghajtót saját céljainkra használhat- 
juk, arra a rendszernek nem lesz szüksége. 

A System Rescue CD alkalmas arra is, hogy USB meghajtó- 
ról (például pendrive eszközről) indítsuk, azonban ha ilyen 
módszerrel szeretnénk használni, akkor a rendszermagnak 
az usbstick paramétert is át kell adnunk induláskor. Termé- 
szetesen a régebbi alaplapokra való tekintettel engedélyez- 
hetjük vagy letilthatjuk az ACPI támogatást, mégpedig az 
acpi-onloff] force paraméterek valamelyikével. 
Előfordulhat, hogy az adott számítógépben, amelyen ezt 

a kellemes eszközt használni szeretnénk, nincsen hálózati 
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1. kép A OTParted felülete 


kártya. Felesleges is lenne tehát az automatikus felismerést 
használni, adjuk meg induláskor a nonet paramétert. Így 
elkerülhetjük a várakozást egy olyan műveletre, aminek 
már tisztában vagyunk az eredményével. Ugyanígy megad- 
ható a noscsi és a nodetect kapcsoló. Használatukkal elke- 
rülhetjük a SCSI eszközök felismerését és teljes egészében 
kikapcsolhatjuk a számítógépben található eszközök felis- 
merését. Szintén hasznos lehetősége ennek az egyszerű 
rendszernek, hogy képes automatikusan elindítani héj- 
programokat. A rendszermag indulásakor megadható az 
ar. source paraméter, amivel azt magyarázhatjuk el az in- 
duló Linuxnak, hogy hol keresse az önműködően indítandó 
programokat. Ilyen programból összesen 10 lehet, elnevezé- 
sük a autorunszZAM megnevezést követi, ahol a SZAM nullá- 
tól kilencig terjedhet. A programokat egymás után sorban 
indítja a rendszer, de ennek a sornak a végrehajtása meg- 
szakad, amint az egyik program hibakóddal tér vissza. 

Az önműködően indítandó programok forrása lehet a CD- 
ROM gyökérkönyvtára, hajlékonylemezes meghajtó, NFS 
vagy Samba megosztás, a rendszergazda saját könyvtára, 
vagy a /usr/share/sys.autorun program. Az autoruns para- 
méter után vesszővel elválasztva meghatározhatjuk azokat 
a programokat, amelyeket ténylegesen szeretnénk elindíta- 
ni. Például ha paraméterként a autoruns-1, 3 , 6 karakter- 
láncot adjuk meg, akkor a rendszer a megtalált programok 
közül sorban elindítja az autorun1, az autorun3 és az 
autorun6 nevű állományokat. Természetesen ezek a progra- 
mok nem csak a héj által értelmezhető szöveges programok 
lehetnek, hanem lefordított, futtatható állományok is. Az 
utolsó paraméter, ami az önműködő programokra vonatko- 
zik, az ar. nowait, amivel elérhetjük, hogy az utolsó prog- 
ram befejeződésével a rendszer ne várakozzon az ENTER bil- 
lentyű leütésére. 


Állítsuk be 


Nézzünk meg néhány egyszerű beállítást, amit a rendszer 
indulása után érdemes elvégezni. Nagyon gyakran van 
szükség arra, hogy hálózati kártyánkat elindítsuk, amit eb- 
ben a rendszerben a net-setup eth0 parancs segítségével 
tehetünk meg. A net-setup program paramétere a be- 
állítandó hálózati csatoló neve. A parancs segítségével egy 
dialog alapú, szöveges felületen állíthatjuk be a szokásos 
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paramétereket. A rendszer elindulása után vírusellenőrzést 
is végezhetünk a Clam AntiVirus programmal. Az ehhez 
szükséges lépések itt olvashatók. Először készítünk egy 
könyvtárat a vírusmeghatározások számára és az ellenőriz- 
ni kívánt fájlrendszer számára a mkdir /virdefs 
/mnt/virtest paranccsal. A következő lépésként a CD-n 
lévő vírusmeghatározásokat átmásoljuk a létrehozott 
könyvtárba. (cp /usr/share/clamav/" /virdefs). Ezután, 
ha rendelkezünk internet-hozzáféréssel és azt be is állítot- 
tuk, akkor a freshclam --datadir /virdefs parancs ha- 
tására a Clam AntiVirus frissíti az adatbázisát és mi pedig 
befűzhetjük az ellenőrizni kívánt fájlrendszert a /mnt/ 
virtest könyvtárba. Következhet a vírusellenőrzés. Adjuk 
kia clamscan -i --bell -r -d /virdefs /mnt/virtest 
parancsot, majd várakozzunk türelmesen. A víruskereső 
ilyen paraméterezéssel csak a fertőzött állományokat írja ki 
a kimenetre és hangjelzéssel jelzi a találatot. A keresés végén 
ne felejtsük el leválasztani umount (umount) a fájlrendszert. 
Nos, elérkeztünk ahhoz a részhez, amikor a felhasználóban 
felmerülhet a kérdés, hogy hogyan is lehetne ezt a hasznos 
rendszert a felmerülő igényekhez igazítani. Szerencsére 

a fejlesztők erre is gondoltak, így néhány meglehetősen 
egyszerű lépéssel teljesen testreszabható a System Rescue 
CD. Először is szükség lesz egy lemezrészre (lehetőleg vala- 
milyen linuxos fájlrendszerrel), amelyen van 500MB szabad 
hely. Ezt a fájlrendszert fűzzük be a /mnt/custom könyv- 
tárba. A következő lépés, az éppen használt rendszer tar- 
talmának kicsomagolása. Ezt könnyedén elvégezhetjük 

a sysrescd-custom extract parancs kiadásával). A pa- 
rancs hatására a /mnt/custom/customcdffiles könyvtárban 
elérhetjük a CD tartalmát, és ide másolhatjuk az esetleges 
önműködően induló programjainkat is, vagy akár beállítha- 
tunk állandó hálózati címet. Egyszerűen szólva igényeink- 
nek megfelelően átalakíthatjuk a rendszert. 

Mindezek után következhet az újabb becsomagolás, a CD- 
lenyomatának (image) elkészítése és az új CD írása. A meg- 
felelő parancsok segítségével készítsük el az újabb változa- 
tot tartalmazó CD-képet: sysrescd-custom cloop 210 
30000. A program elkészíti az újabb lenyomat létrehozásá- 
hoz szükséges tömörített fájlrendszert, 210MB mérettel és 
legfeljebb 30000 állomány tárolására alkalmas formában. 

A szabadon beállított változatnak megadhatunk alapértel- 
mezett billentyűzetkiosztást is, mégpedig a sysrescd- 
custom setkeymap hu parancs segítségével. Ebben az eset- 
ben az alapértelmezett kiosztás a magyar billentyűzetnek 
megfelelő lesz. Végül pedig utolsó lépés a CD-lenyomat 
létrehozása: sysrescd-custom isogen KOTETCIMKE. Ahol 

a KOTETCIMKE lesz majd az új CD neve. Az elkészített állo- 
mányt a /mnt/custom/customcd/isofile/ elérési úton találjuk 
meg, sysresccd-new.iso néven. 

A rendszer tartalmazza a cdrecord programot is, tehát 

a CD-író meghajtónk felismerése után máris kiírhatjuk 
legújabb életmentő lemezünket. 

Sajnos ebben a rövidke leírásban nem tudtam mindent 
bemutatni, amire képessé válhatunk a System Rescue CD 
használatával, de szerencsére a rendszer elindulása után 

a /root/manual-en/index.html leírásból kiindulva, a links 
böngészővel minden részletre fény derülhet. 


Fábián Zoltán 
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